At the end of the day, the most important thing is that you are consistent. If you have to swallow your pride and adopt a standard that you don’t agree with to mirror the standards of an existing codebase or company standard, just do it!
Este discutia asta una din cele in care ne expunem opinia? Eu asa am inteles. Daca nu este, rog un moderator sa-mi stearga comentariul.
Eu prefer sa fie pe aceeasi linie, deoarece de multe ori am codul intr-o fereastra mica (gen 600x900 px din fereastra e dedicat pentru cod), si cele cateva linii in plus sunt inlocuite de cod. Cu alte cuvinte, codul este mai compact.
Daca as avea un monitor dedicat doar pentru cod (rotit cu 90 de grade, adica 9:16 in loc de 16:9), probabil asta nu ar mai fi o problema. Asta este si unul din motivele pentru care am trecut de la IDE-uri (gen PHPstorm) la editoare de text (gne Brackets): Mai putin spatiu ocupat de meta (non-cod).
Jur ca nu mi-a pasat niciodată. Singura mea problemă a fost ca nu știam cum să o așez pe vremea cand faceam “code formatul” de mana.
Acum atâta timp cât acum exista standarde (PSR pentru PHP) sau configăre (vezi eslint pentru JS) de care IDE-ul meu are habar, nu mai am nicio grija: CTRL+AL+L
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
I guess that settles it for PHP?
iar exemplul lor:
<?php
namespace Vendor\Package;
use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;
class Foo extends Bar implements FooInterface
{
public function sampleMethod($a, $b = null)
{
if ($a === $b) {
bar();
} elseif ($a > $b) {
$foo->bar($arg1);
} else {
BazClass::bar($arg2, $arg3);
}
}
final public static function bar()
{
// method body
}
}
cu four spaces arata ok IMO - extra spacing vertical si orizontal makes it look ok si asta desi sunt two space junkie.
La începutul carierei, puneam curly pe un rând cu altceva, stilul k&r părându-mi-se greu de citit. Cu timpul, ceva s-a schimbat în creierul meu, preferând k&r tot mai mult.
Ce nu am înțeles este asta:
De ce la metode e într-un fel, la loop-uri/if-uri în alt fel?
Spațiul ocupat de UI-ul unei aplicații se numește chrome.
Definition: Chrome is the visual design elements that give users information about or commands to operate on the screen’s content (as opposed to being part of that content). These design elements are provided by the underlying system — whether it be an operating system, a website, or an application — and surround the user’s data. sursa
one thing per line: numele clasei/metodei (“cum ii zice”) pe un rand plus acolada “incepe” pe alt rand
la structuri de control ai deja pe linie if/switch/while/etc, ca acolo incepe si nu mai conteaza sa ai o linie separata “noah amu incepe”, fiindca e redundant
(juma’ de an mi-a luat sa ma obisnuiesc cu ele asa, si eu le scriam toate pe un rand)
public abstract class AbstractController extends WebContentGenerator implements Controller {
private boolean synchronizeOnSession = false;
/**
* Create a new AbstractController which supports
* HTTP methods GET, HEAD and POST by default.
*/
public AbstractController() {
this(true);
}
/**
* Create a new AbstractController.
* @param restrictDefaultSupportedMethods {@code true} if this
* controller should support HTTP methods GET, HEAD and POST by default,
* or {@code false} if it should be unrestricted
* @since 4.3
*/
public AbstractController(boolean restrictDefaultSupportedMethods) {
super(restrictDefaultSupportedMethods);
}
Pana acum cativa ani, nu exista un standard si fiecare scria codul cum dorea sau dupa conventii interne.
O data cu votul acordat de comunitate pt PSR, mi se pare normal ca treptat toate echipele si proiectele sa migreze codul catre standard. Deja framework-urile majore au adoptat o parte din PSR-uri printre care si cele legate de scrierea codului.
IDE-urile stiu sa formateze codul, in screenshot e PHPStorm, iar la Predefined are optiunea PSR1/PSR2:
long day.