Is-gelijk-aan-tekens uitlijnen?

[ONiel]

Hey

Ik vroeg me het volgende af.
Om je code er mooi uit te laten zien, moet je dan tab (of spaces) gebruiken om
je is-gelijk-aan-tekens onder mekaar te zetten?

Dit is namelijk iets wat ik veel zie:

code:

$variable1  = $_POST["variable1"];
$var2       = $_POST["var2"];

De variabel-namen zijn niet evenlang, maar toch staan de is-gelijk-aan-tekens onder elkaar.
Is dit goed om te doen? Mogelijk in elke taal? Sommige talen zijn namelijk soms wel eens heel spatie-afhankelijk (zoals e.g Python).
Ik programmeer meestal Stroustrup-style als dat er toe doet, en deed tot nu toe gewoon een spatie tussen het is-gelijk-aan-teken.

Bedankt!

[P-Storm]

Wat je ziet is een effect van een monospaced. Hierdoor is de afstand mogelijk de zelfde grote, aangezien elke karakter even groot is. Er zullen vast tooltjes zijn die dit automatisch voor je doen. Vaak is de IDE waarin je programmeert in te stellen welke font je gebruikt.

Het effect van tabs is ook per IDE verschillend, geen idee of de uitlijning dan net zo goed uitkomt.

link gefixed

[ Voor 3% gewijzigd door .oisyn op 13-10-2016 15:37 ]

[cannibal]

Persoonlijk ben ik van dit soort uitlijning al een tijdje afgestapt en gebruik ik alleen nog de uitlijning welke geleverd wordt door de tool die ik gebruik (Visual Studio, Resharper, Notepad++). Teveel werk om een code-file niet automatisch te kunnen her-structureren en teveel werk om anders elke keer als een variable-naam te lang wordt alles opnieuw te gaan spatiëren / tabificeren.

[Gropah]

Tabs vs spatie's is een heilige oorlog voor sommige, persoonlijk houd ik aan dat ik indenting doe met tabs en alignment met spaties. Zie ook deze post. Omdat iedereen andere tablengtes kan instellen wil je dus niet dat dingen die op dezelfde hoogte moeten zitten op bepaalde plekken midden in een regel code met tabs dun. Ik zou dus spatie's gebruiken voor het uitlijnen van de =-tekens.

Sommige talen zijn inderdaad gevoelig voor de indenting, maar (afaik) gaat het dan puur om de tabs of spatie's aan het begin van een regel, om aan te geven hoe "diep" je in de code zit (dus of je een for-loop oid in springt, zie hiervoor ook de gelinkte post).

[staaltje]

Niet doen. Cannibal geeft al aan dat je telkens als de langste variabele verandert, je de complete declaratie opnieuw moet uitlijnen. Dat betekent dat regels waarin je eigenlijk niets semantisch hebt gewijzigd wel veranderd worden. Dat maakt het lastiger als je in je versiebeheersysteem wil gaan terugzoeken naar de laatste 'echte' wijziging. De 'annotate' functie waarmee je van elke regel kunt zien wanneer, door wie en met welk comment hij is gecommit wordt dan waardeloos.

[ Voor 0% gewijzigd door staaltje op 12-10-2016 21:44 . Reden: typo's ]

[begintmeta]

Zelfs op wikipedia is hier iets over te vinden, helaas slechts vrij oppervlakkig en zonder literatuurverwijzingen: Wikipedia: Programming style

[Verwijderd]

Ben je de enige programmeur op het project? Doe dan wat je goeddunkt maar houd je daar wel aan. Werk je met meerdere programmeurs? Maak dan afspraken over welke stijl je gebruikt en houd je daar aan. Heel simpel, het kan geen kwaad maar het is ook overbodig.

Maar ga vooral niet dingen door elkaar doen.

[ Voor 8% gewijzigd door Verwijderd op 12-10-2016 21:51 ]

[Feanathiel]

Puur een mening, maar ik vind het niet lastig lezen. Je zit constant te ping-pongen en wellicht dat je per ongeluk ook nog eens een verkeerde variabele pakt:

PHP:

$langeVariabeleNaamDieEigenlijkTochBestWelLangIs = $_POST['lang'];
$kort                                            = $_POST['kort'];
$andere                                          = $_POST['andere'];
$nummer                                          = $_POST['nummer'];
$var                                             = $_POST['var'];

Daarnaast (auto-)merged het niet fijn, omdat de uitlijning vaak verkeerd is wanneer je iets nieuws hebt toegevoegd.

[Zeror]

Je moet kijken of de taal waarin je wilt programmeren de spaties en/of tabs uitgelezen of genegeerd worden. Daarna is het gewoon een persoonlijke voorkeur (wel of geen goede programmeergewoonte).

[b2vjfvj75gjx7]

Ook handig om te weten is dat tabs soms een functie hebben, bv. in SASS of YAML.

code:

hello
world
foo
bar

Bovenstaande is heel anders dan;

code:

hello
  world
    foo

bar

"Vroeger" maakte ik van mijn codes echt ascii-verantwoorde-typografische-kunst, qua uitlijning (het oogte mooier dan het werkte, bij wijze van), sinds een jaar of vijf pak ik inderdaad de conventies van de IDE en zorg ik op andere manieren dat het leesbaar is (nesting, accolades, semi-columns, etc...).

[bwerg]

Niets nieuws hier maar een bevestiging van bovenstaande, altijd leuk als:
- je in code van anderen werkt en ze hebben dingen met tabs uitgelijnd, maar de uitlijning is juist slecht omdat je eigen tab-instellingen anders zijn. Als je uitlijnt, doe het met spaties.
- Je dan netjes uitlijnt met spaties, en je springt in met tabs, dan krijg je soms weer een bak compiler-warnings over 'mixed tabs and spaces', wat inderdaad ook niet heel netjes is.
- je iets toevoegt en je 20 regels erboven/onder moet gaan fixen om de uitlijning weer kloppend te maken.

Overal nadelen, en dat alles omdat het er een beetje leuker uitziet.

[Cartman!]

Binnen PHP zou ik me houden aan de PSR-1 en PSR-2 standaarden. Vrijwel alle grote libraries en frameworks houden zich hieraan en de ondersteuning voor IDE's en tools is zeer groot.

[Barryvdh]

Cartman! schreef op donderdag 13 oktober 2016 @ 09:35:
Binnen PHP zou ik me houden aan de PSR-1 en PSR-2 standaarden. Vrijwel alle grote libraries en frameworks houden zich hieraan en de ondersteuning voor IDE's en tools is zeer groot.

Dit inderdaad.
Ik zou ze niet uitlijnen met extra spaties. Persoonlijk gebruik ik gewoon PhpStorm -> Reformat code als het iets heel anders is, dan staat het meteen in PSR-2 netjes (Als je dat iig instelt as code style). En in jouw voorbeeld zet hij dan de variabelen weer recht achter elkaar

[jomas]

ONiel schreef op woensdag 12 oktober 2016 @ 21:31:
Hey

Ik vroeg me het volgende af.
Om je code er mooi uit te laten zien, moet je dan tab (of spaces) gebruiken om
je is-gelijk-aan-tekens onder mekaar te zetten?

Voor b.v. Python moet je geen '=' tekens uitlijnen. Python heeft bepaalde richtlijnen b.v. PEP8 die dit afraden.
Dit om uitwisseling van code onderling te vergemakkelijken.

[aap]

Regel 1: als je met anderen samenwerkt, spreek dan af hoe je hiermee omgaat, zodat iedereen hetzelfde doet. Anders ontketen je misschien een heilige oorlog op je werk.

Als je alleen werkt: doe wat je zelf handig lijkt.

Mijn persoonlijke voorkeur: ik gebruik alleen spaties; dan ziet je code er in iedere editor met welke instellingen dan ook er hetzelfde uit. Het nadeel is dan wel dat je de inspring-diepte niet achteraf eenvoudig meer aan kunt passen (of dat ieder zijn eigen voorkeuren kan instellen). Maar tabs en spaties mixen geeft vroeg of laat altijd gedoe, zeker in talen waar de indent er functioneel toe doet (bijv. Python)

Uitlijnen van = tekens doe ik ook. Draagt bij aan de leesbaarheid, maar is zoals al aangestipt onderhoudsgevoeliger. Een editor waarin je een aantal kolommen over meerdere rijen tegelijk kunt opschuiven helpt daarbij.

[SPee]

Ik zou nooit meer dan 2 extra spaties gebruiken om dingen "uit te lijnen".
Als je dan zulke dingen krijgt als @Feanathiel dan is het op een gegeven moment lastig om te bepalen waar die waarde bij hoort.
Als je eenmaal begint, waar eindig je dan? Hoeveel whitespaces is de max?

Het is niet moeilijker om te lezen zonder al die witte ruis.

[Compizfox]

Alignment doe je altijd met spaties, los van het feit of je tabs of spaties voor indentation gebruikt.

[Verwijderd]

Spaties of Tabs, het maakt niet veel uit en is puur wat je voorkeur is. Ikzelf zweer heilig bij tabs en begin te vloeken van spaties. De volgende developer heeft het weer direct andersom.

Overigens raad ik je het uitlijnen af. Heb dat zelf vroeger ook altijd gedaan, maar je bent op een gegeven moment gewoon veel tijd kwijt bij het corrigeren wanneer je mutaties doorvoert en het voegt verder weinig toe.

[Dido]

Of je zorgt gewoon dat je verplicht al je variabelen dezelfde lengte geeft. 8 karakters moet genoeg zijn.

[.oisyn]

Dido schreef op donderdag 13 oktober 2016 @ 15:28:
Of je zorgt gewoon dat je verplicht al je variabelen dezelfde lengte geeft. 8 karakters moet genoeg zijn.

8? 1 is genoeg, met de gehele unicode range tot je geschikking

[begintmeta]

aap schreef op donderdag 13 oktober 2016 @ 13:00:
... gebruik alleen spaties; dan ziet je code er in iedere editor met welke instellingen dan ook er hetzelfde uit. ...

Lettertypeinstellingen kunnen wel uitmaken.

.oisyn schreef op donderdag 13 oktober 2016 @ 15:41:
[...]


8? 1 is genoeg, met de gehele unicode range tot je geschikking

De variabele ' ' van ' ' of zelfs ' ', ' ' of ' ' te onderscheiden lijkt me niet altijd even makkelijk. Daarnaast zijn er wellicht ook wel argumenten te geven voor bepaalde uitgebreidere variabelennamen.

[DJMaze]

Ik gebruik spaties in de uitlijning en heb totaal niet de problemen die men beschrijft.
Mijn editor (Geany) heeft namelijk vertical/box/multi-line select.
Een filmpje legt het uit voor Visual Studio 2010 YouTube: Box Selection and Multi-Line Editing Demo

Bijna elke editor ondersteund het

[ Voor 8% gewijzigd door DJMaze op 13-10-2016 16:19 ]

[aap]

begintmeta schreef op donderdag 13 oktober 2016 @ 16:13:
[...]

Lettertypeinstellingen kunnen wel uitmaken.

Tja, als iemand niet-proportionele fonts gebruikt, dan is iedere uitlijning gedoemd te mislukken. Zolang je geen tabs en spaties mixt, zullen in ieder geval de inspringspaties nog wel netjes uitlijnen. Nog een argument of nooit tabs en spaties te mixen.

Ik heb overigens nog nooit gezien dat iemand die serieus ontwikkelde een editor gebruikte met een niet-proportioneel font. En ik heb toch best een aantal collega'smet vrij excentrieke ontwikkelvookeuren....

[mashell]

Ja, dit is goed om te doen. Het zorgt er voor dat als er commentaar achter zet dit commentaar ook uitgelijnd is en daarnee gemakkelijker te lezen als passend bij de toewijzing.
Ik ben hier er voor, altijd uitlijnen met staties. Tabs hebben in source code niks te zoeken (soms open je code in andere tools zoals debuggers en die kunnen een andere tab diepte gebruiken).
Maar het werkt eigenlijk als je niet al te veel waarde hecht aan de oude regel dat je regel niet langer mag zijn dan 80 karakters.

[Compizfox]

Verwijderd schreef op donderdag 13 oktober 2016 @ 15:23:
Spaties of Tabs, het maakt niet veel uit en is puur wat je voorkeur is. Ikzelf zweer heilig bij tabs en begin te vloeken van spaties. De volgende developer heeft het weer direct andersom.

Voor inspringing (indentation) ja. Uitlijnen met tabs is gewoon fout. Daar zijn tabs niet voor bedoeld, en als je dan de tab size wijzigt, klopt de uitlijning niet meer.

---

aap schreef op donderdag 13 oktober 2016 @ 16:33:
[...]

Zolang je geen tabs en spaties mixt, zullen in ieder geval de inspringspaties nog wel netjes uitlijnen. Nog een argument of nooit tabs en spaties te mixen.

Misschien begrijp ik je verkeerd, maar als je tabs gebruikt voor inspringing, moet je juist wel tabs en spaties 'mixen'. Je moet namelijk altijd spaties gebruiken voor uitlijnen, ongeacht of je tabs of spaties gebruikt voor inspringing.

Tabs gebruiken voor uitlijnen werkt niet en is fout.

---

mashell schreef op donderdag 13 oktober 2016 @ 17:42:
Ja, dit is goed om te doen. Het zorgt er voor dat als er commentaar achter zet dit commentaar ook uitgelijnd is en daarnee gemakkelijker te lezen als passend bij de toewijzing.
Ik ben hier er voor, altijd uitlijnen met staties. Tabs hebben in source code niks te zoeken (soms open je code in andere tools zoals debuggers en die kunnen een andere tab diepte gebruiken).

Was het met je eens, tot die laatste zin

Tabs hebben wel wat te zoeken in source code, maar alleen als inspringing. Nooit voor uitlijnen.

Het voordeel van tabs is dat iedereen voor zich de tab size kan aanpassen naar wat diegene fijn vindt (2, 4, of 8 ). Zo kun je samen in een team werken aan dezelfde code, terwijl iedereen z'n eigen voorkeur qua tab size gebruikt. Met spaties kan dit niet, omdat die 'hard' in de source code staan.

Ik vind daarom tabs beter omdat de tab size een vorm-kwestie is, geen content-kwestie. Het zou dus niet vast moeten liggen in de source code, zoals dat bij spaties het geval is.

Zo lang je consequent tabs for indentation, spaces for alignment aanhoudt, blijft alles netjes uitgelijnd, ook bij het aanpassen van de tab size. Zie ook: https://www.emacswiki.org/emacs/SmartTabs

[ Voor 76% gewijzigd door Compizfox op 13-10-2016 17:58 ]

[b2vjfvj75gjx7]

Ook leuk als je variabele van naam verandert en je de boel netjes uitgelijnd wil houden...

code:

$primaryProduct = "Foobar";
$price          = 123.50;
$sku            = "48-a";

En dan bepaalt iets of iemand dat $primaryProduct opeens $mainProduct moet heten;

code:

$mainProduct = "Foobar";
$price       = 123.50;
$sku         = "48-a";

Dan moet je dus ook alle uitlijningen aanpassen (3x in dit geval), omdat het anders niet netjes leest...

Vandaar dat ik gewoon doe;

code:

$primaryProduct = "Foobar";
$price = 123.50;
$sku = "48-a";

...niet mooi - wel effectief

[mashell]

Compizfox schreef op donderdag 13 oktober 2016 @ 17:47:
[...]
Het voordeel van tabs is dat iedereen voor zich de tab size kan aanpassen naar wat diegene fijn vindt (2, 4, of 8 ). Zo kun je samen in een team werken aan dezelfde code, terwijl iedereen z'n eigen voorkeur qua tab size gebruikt. Met spaties kan dit niet, omdat die 'hard' in de source code staan.

En dat is dus ook precies de bedoeling. Met welke tool, welke editor op welk bureau je de code ook bekijkt, het ziet er altijd hetzelfde uit. Voor persoonlijke voorkeuren is in bedrijven eigenlijk nooit ruimte. Er zijn vrijwel altijd code guidelines. En daar staat eigenlijk altijd in: tabs worden niet gebruikt. En er wordt een vaste identatie voorgeschreven.

[Verwijderd]

Dido schreef op donderdag 13 oktober 2016 @ 15:28:
Of je zorgt gewoon dat je verplicht al je variabelen dezelfde lengte geeft. 8 karakters moet genoeg zijn.

Als je het jezelf moeilijk wilt maken, zeker doen

[b2vjfvj75gjx7]

Verwijderd schreef op donderdag 13 oktober 2016 @ 18:20:
[...]


Als je het jezelf moeilijk wilt maken, zeker doen

Al mijn variabelen zijn exact 8.1.3 van formaat

...DOS conventie, anyone (niet, dus)...

[Compizfox]

mashell schreef op donderdag 13 oktober 2016 @ 18:19:
[...]
Er zijn vrijwel altijd code guidelines. En daar staat eigenlijk altijd in: tabs worden niet gebruikt. En er wordt een vaste identatie voorgeschreven.

Dat is juist het punt: met spaties zit je gedwongen vast aan een bepaalde indentation size. Als mensen binnen een team (dat spaties gebruikt) verschillende sizes door elkaar gaan gebruiken, dan gaat het mis.

Tabs lossen dit probleem op. Het is een semantisch betere oplossing voor inspringen dan spaties, want 1 tab is altijd 1 inspring-niveau. Dat is het enige wat je hoort vast te leggen in de code, de grootte van die tab is een kwestie van vorm, niet van content.

En dat is dus ook precies de bedoeling. Met welke tool, welke editor op welk bureau je de code ook bekijkt, het ziet er altijd hetzelfde uit. Voor persoonlijke voorkeuren is in bedrijven eigenlijk nooit ruimte.

Het hoeft er helemaal niet hetzelfde uit te zien. Het lettertype, het kleurenschema en de tekstgrootte leg je toch ook niet vast in je code? Dat kan elke dev lekker zo instellen in z'n editor/IDE zoals hij fijn vindt. Voor indentation size geldt dit net zo goed: dit hoort niet vast te liggen in de code. Daarom zijn tabs beter.

[EvilWhiteDragon]

mashell schreef op donderdag 13 oktober 2016 @ 18:19:
[...]

En dat is dus ook precies de bedoeling. Met welke tool, welke editor op welk bureau je de code ook bekijkt, het ziet er altijd hetzelfde uit. Voor persoonlijke voorkeuren is in bedrijven eigenlijk nooit ruimte. Er zijn vrijwel altijd code guidelines. En daar staat eigenlijk altijd in: tabs worden niet gebruikt. En er wordt een vaste identatie voorgeschreven.

Volgens diezelfde logica kan je net zo goed altijd tabs gebruiken, immers heeft iedereen toch dezelfde instellingen. Scheelt weer 3x op het toetsenbord rammen

[Cartman!]

Verwijderd schreef op donderdag 13 oktober 2016 @ 15:23:
Ikzelf zweer heilig bij tabs en begin te vloeken van spaties.

Dan hoop ik niet voor je dat je PHP developer bent gezien de PSR coding standards

[Barryvdh]

EvilWhiteDragon schreef op donderdag 13 oktober 2016 @ 19:08:
[...]

Volgens diezelfde logica kan je net zo goed altijd tabs gebruiken, immers heeft iedereen toch dezelfde instellingen. Scheelt weer 3x op het toetsenbord rammen

3x op toetsenbord rammen? Je IDE zet gewoon 4 spaties neer als je op de tab knop drukt.. Er zit voor mij iig 0 verschil in of ik nu tabs of spaties gebruik in php storm, afhankelijk van de instellingen zet hij neer wat nodig is.

[Verwijderd]

Cartman! schreef op donderdag 13 oktober 2016 @ 20:41:
[...]

Dan hoop ik niet voor je dat je PHP developer bent gezien de PSR coding standards

Zowel Sublime als git lossen dat voor ons op

[DJMaze]

Cartman! schreef op donderdag 13 oktober 2016 @ 20:41:
Dan hoop ik niet voor je dat je PHP developer bent gezien de PSR coding standards

Ik ben PHP developer en ik gebruik geen PSR, ik vloek er zelfs op. Wat ga je nu doen, mij vervloeken dat ik mij niet aan de zoveelste standaard hou? Verbannen?

XKCD heeft een mooie afbeelding voor de PSR en dit topic

[Siebsel]

DJMaze schreef op vrijdag 14 oktober 2016 @ 01:37:
[...]

Ik ben PHP developer en ik gebruik geen PSR, ik vloek er zelfs op. Wat ga je nu doen, mij vervloeken dat ik mij niet aan de zoveelste standaard hou? Verbannen?

XKCD heeft een mooie afbeelding voor de PSR en dit topic
[afbeelding]

Noem jij dan eens een paar van de andere standaarden binnen PHP waar een groot aantal (grotere) projecten zich aan houden als je geen PSR wil gebruiken? Meestal ben ik het eens met die afbeelding, alleen in dit geval zit je er (imho) wel naast. Of je het gebruikt of niet is natuurlijk je eigen keuze en ben je geheel vrij in, maar je kunt niet onder het feit uit dat PSR1 en PSR2 inmiddels wel min of meer de standaard is.

[Barryvdh]

Siebsel schreef op vrijdag 14 oktober 2016 @ 09:33:
[...]


Noem jij dan eens een paar van de andere standaarden binnen PHP waar een groot aantal (grotere) projecten zich aan houden als je geen PSR wil gebruiken? Meestal ben ik het eens met die afbeelding, alleen in dit geval zit je er (imho) wel naast. Of je het gebruikt of niet is natuurlijk je eigen keuze en ben je geheel vrij in, maar je kunt niet onder het feit uit dat PSR1 en PSR2 inmiddels wel min of meer de standaard is.

En binnenkort PSR-12
https://github.com/php-fi...ded-coding-style-guide.md

[emnich]

Doe gewoon lekker wat je wilt en wat voor jou het beste is/voelt. Met een goede IDE is het sowieso vrij makkelijk allemaal om te zetten als je besluit het later anders te doen.

Alleen als je in een team werkt moet je je aanpassen aan de standaarden die daar gebruikt worden. Zeker met het oog op versiebeheer.

[Siebsel]

emnich schreef op vrijdag 14 oktober 2016 @ 09:54:
Doe gewoon lekker wat je wilt en wat voor jou het beste is/voelt. Met een goede IDE is het sowieso vrij makkelijk allemaal om te zetten als je besluit het later anders te doen.

Alleen als je in een team werkt moet je je aanpassen aan de standaarden die daar gebruikt worden. Zeker met het oog op versiebeheer.

Hear, hear. Precies dit.

[Cartman!]

DJMaze schreef op vrijdag 14 oktober 2016 @ 01:37:
[...]

Ik ben PHP developer en ik gebruik geen PSR, ik vloek er zelfs op. Wat ga je nu doen, mij vervloeken dat ik mij niet aan de zoveelste standaard hou? Verbannen?

Zit de haat voor spaties zo diep bij je? Ik hoef je niet te verbannen of te vervloeken. Ik vind het zelf veel nuttiger me aan de algemene standaard te houden omdat elke library en framework waarmee ik werk dat ook doet.

XKCD heeft een mooie afbeelding voor de PSR en dit topic
[afbeelding]

Behalve dat er voor PHP geen 14 standaarden zijn maar slechts 1 dus deze gaat imo gewoon niet op.

[mashell]

Compizfox schreef op donderdag 13 oktober 2016 @ 18:39:
[...]
Dat is juist het punt: met spaties zit je gedwongen vast aan een bepaalde indentation size. Als mensen binnen een team (dat spaties gebruikt) verschillende sizes door elkaar gaan gebruiken, dan gaat het mis.

Tabs lossen dit probleem op. Het is een semantisch betere oplossing voor inspringen dan spaties, want 1 tab is altijd 1 inspring-niveau. Dat is het enige wat je hoort vast te leggen in de code, de grootte van die tab is een kwestie van vorm, niet van content.

Het hoeft er helemaal niet hetzelfde uit te zien. Het lettertype, het kleurenschema en de tekstgrootte leg je toch ook niet vast in je code? Dat kan elke dev lekker zo instellen in z'n editor/IDE zoals hij fijn vindt. Voor indentation size geldt dit net zo goed: dit hoort niet vast te liggen in de code. Daarom zijn tabs beter.

Tja. Normaal gesproken werk toch iedereen met een proportioneel courier lettertype voor source code. Als je als bedrijf al verschillende editors toestaat (meestal is er een standaard, en wie daarvan af wil wijken mag dat maar die mag geen schade veroorzaken) juist dan wordt het van belang dat je tabs = x spaties vastlegt.

Identation regels liggen vast in de code guidelines met als doel dat het in elke tool, van editor tot debugger hetzelfde is. Dat doe je door tabs te verbieden en identations op x spaties vast te leggen. Lekker instellen zoals ieder het fijn vindt zie ik eigenlijk nooit bij bedrijven (multinationals, productontwikkeling). In mijn omgeving is het gebruik van tabs absoluut not done.

[Compizfox]

mashell schreef op vrijdag 14 oktober 2016 @ 10:37:
[...]

Tja. Normaal gesproken werk toch iedereen met een proportioneel courier lettertype voor source code.

Er bestaan meer monospace-fonts dan Courier New...

Als je als bedrijf al verschillende editors toestaat (meestal is er een standaard, en wie daarvan af wil wijken mag dat maar die mag geen schade veroorzaken) juist dan wordt het van belang dat je tabs = x spaties vastlegt.

Identation regels liggen vast in de code guidelines met als doel dat het in elke tool, van editor tot debugger hetzelfde is. Dat doe je door tabs te verbieden en identations op x spaties vast te leggen. Lekker instellen zoals ieder het fijn vindt zie ik eigenlijk nooit bij bedrijven (multinationals, productontwikkeling). In mijn omgeving is het gebruik van tabs absoluut not done.

Als je spaties gebruikt, ja. Met tabs maakt het niet uit en kan iedereen gebruiken wat hij zelf fijn vindt. Dat is juist het voordeel van tabs boven spaties (zoals ik probeerde uit te leggen in mijn vorige comment).

[ Voor 24% gewijzigd door Compizfox op 14-10-2016 11:28 ]

[mashell]

Compizfox schreef op vrijdag 14 oktober 2016 @ 11:26:
Als je spaties gebruikt, ja. Met tabs maakt het niet uit en kan iedereen gebruiken wat hij zelf fijn vindt. Dat is juist het voordeel van tabs boven spaties (zoals ik probeerde uit te leggen in mijn vorige comment).

Wat iemand fijn vindt is helaas niet zo relevant. Het gaat erom dat je code er altijd hetzelfde uitziet. Dus in je editor, in notepad, in een cat in bash, in je versiebeheer tool, in je comparetool, in een debugger, uitgeprint op papier. Altijd! Als je een identatie van 4 spaties gebruikt en jij stelt je tabstop in op 4 om daarbij aan te sluiten en je projectleider dan de code afdrukt voor een review het er weer heel anders uitziet omdat hij een andere editior (misschien zelfs wel Microsoft Word) gebruikt, dan is dat onhandig voor zowel hem als jou bij het verwerken van het reviewcommentaar. Daarom altijd spaties en nooit tabs. Als je in je code editor gewoon je tab toets instelt op de afgesproken x spaties, zit je altijd goed. Ja, dan moet je even wennen als jij liever y spaties inspringing gebruikt maar dat is klein leed in vergelijk met alle voordelen die het biedt om de code altijd hetzelfde verschijningsbeeld te laten hebben. De grootste gruwel is tabs en spaties door elkaar gebruiken, daarom wordt er dus meestal voor het niet variabele van de twee gekozen, de spatie.

[Compizfox]

mashell schreef op vrijdag 14 oktober 2016 @ 11:51:
[...]

Wat iemand fijn vindt is helaas niet zo relevant. Het gaat erom dat je code er altijd hetzelfde uitziet. Dus in je editor, in notepad, in een cat in bash, in je versiebeheer tool, in je comparetool, in een debugger, uitgeprint op papier. Altijd!

Waarom zou dat zo moeten zijn? Sorry, maar ik snap gewoon niet waarom jij dit zo belangrijk vindt. Code ziet er niet overal hetzelfde uit, en dat hoeft ook niet. Ik gebruik misschien tab size 4, Monokai en Courier New, iemand anders weer tabs size 8, Zenburn en DejaVu Sans Mono. Nou en? Prima toch?

Ik zie het juist als een voordeel van tabs dat het er niet overal hetzelfde uit hoeft te zien. Met spaties is dit een vereiste omdat het anders misgaat, met tabs bestaat dat probleem gewoon niet.

Als je een identatie van 4 spaties gebruikt en jij stelt je tabstop in op 4 om daarbij aan te sluiten en je projectleider dan de code afdrukt voor een review het er weer heel anders uitziet omdat hij een andere editior (misschien zelfs wel Microsoft Word) gebruikt, dan is dat onhandig voor zowel hem als jou bij het verwerken van het reviewcommentaar. Daarom altijd spaties en nooit tabs. Als je in je code editor gewoon je tab toets instelt op de afgesproken x spaties, zit je altijd goed.

Dit argument kun je ook prima andersom gebruiken. Als iedereen tabs gebruikt, zit je net zo goed altijd goed.

Ja, dan moet je even wennen als jij liever y spaties inspringing gebruikt maar dat is klein leed in vergelijk met alle voordelen die het biedt om de code altijd hetzelfde verschijningsbeeld te laten hebben. De grootste gruwel is tabs en spaties door elkaar gebruiken, daarom wordt er dus meestal voor het niet variabele van de twee gekozen, de spatie.

Tabs en spaties door elkaar gebruiken is juist wel noodzakelijk om te zorgen dat uitlijning correct blijft werken bij het aanpassen van tab size. (tabs for indentation, spaces for alignment)
Als je denkt dat je tabs hoort te gebruiken voor alignment heb je het niet begrepen (en snap ik meteen je aversie voor tabs wel ).

[ Voor 48% gewijzigd door Compizfox op 14-10-2016 12:30 ]

[CH4OS]

Op kantoor gebruiken wij PSR-2, gebruiken enkel spaties (1 tab is 4 spaties). Bij mijn hobby projecten thuis maakt het mij niet zo heel veel uit, eigenlijk. Ik kan SublimeText op zich vrij simpel forceren naar PSR-2 inclusief een Linter, maar vind het prima zo, zolang het maar doet wat het moet doen en ik het leesbaar vind.

Waar ik aan de andere kant ook benieuwd naar ben (al is het iets buiten de scope van het topic wellicht) is hoeveel jullie codesniffing gebruiken.

Ikzelf gebruik het op het werk redelijk, zou het thuis ook wel willen, maar helaas heeft SublimeText 3 daar geen native support voor. Zijn plugins voor, maar die werken bij mij gammel. Zit daarom ook te kijken naar andere IDE's / editors, maar nog niet echt een mooie alternatief voor gevonden.

[mashell]

Compizfox schreef op vrijdag 14 oktober 2016 @ 12:21:
[...]

Waarom zou dat zo moeten zijn? Sorry, maar ik snap gewoon niet waarom jij dit zo belangrijk vindt. Code ziet er niet overal hetzelfde uit, en dat hoeft ook niet. Ik gebruik misschien tab size 4, Monokai en Courier New, iemand anders weer tabs size 8, Zenburn en DejaVu Sans Mono. Nou en? Prima toch?

Ik zie het juist als een voordeel van tabs dat het er niet overal hetzelfde uit hoeft te zien. Met spaties is dit een vereiste omdat het anders misgaat, met tabs bestaat dat probleem gewoon niet.


[...]

Dit argument kun je ook prima andersom gebruiken. Als iedereen tabs gebruikt, zit je net zo goed altijd goed.

[...]

Tabs en spaties door elkaar gebruiken is juist wel noodzakelijk om te zorgen dat uitlijning correct blijft werken bij het aanpassen van tab size. (tabs for indentation, spaces for alignment)
Als je denkt dat je tabs hoort te gebruiken voor alignment heb je het niet begrepen (en snap ik meteen je aversie voor tabs wel ).

We ontsporen een beetje van het hoofdtopic.
Ik denk dus niet dat je tabs voor aligment moet gebruiken. Ik denk dat je tabs helemaal nergens anders dan in Microsoft Word zou moeten willen gebruiken (en zelfs daar ben je met een tabel meestal beter af).
Indentation doe je met de tab toets. De levert je (afhankelijk van de coding guidelines 2,3 of 4 spaties) maar nooit een echte tab. Dat zorgt ervoor dat ik, mijn eigen code, in willekeuring welk tool ik wil gebruiken of moet gebruiken (debuggers, compare tools, pcs van collega's) altijd kan herkennen en zonder nadenken over persoonlijke lokale settings kan bewerken. Dat is gewoon veel efficienter werken. Als je in je 1tje een project in alleen Visual studio maakt dan maakt het niet zoveel uit. Maar werk je meerdere mensen aan dezelfde code en gebruik je veel verschillende tools dan maakt het heel erg uit. Als je bijvoorbeeld met git op de commandline een code merge doet is een tab size van 8 (de standaard op een commandline) gewoon erg onhandig.
Als iedereen tabs gebruik gaat het altijd mis omdat niet alle tools dezelfde instellingsmogelijkheden bieden. het belang zit hem dus in het gebruik van dezelfde code in verschillende tools door verschillende mensen op verschillende machines.

[.oisyn]

mashell schreef op vrijdag 14 oktober 2016 @ 11:51:
[...]

Wat iemand fijn vindt is helaas niet zo relevant. Het gaat erom dat je code er altijd hetzelfde uitziet.

Daar gaat het helemaal niet om, dat is wat jij ervan maakt. Het gaat erom dat de code leesbaar is en dus correct geïndenteerd. Zeg nou eerlijk, maakt het voor een stuk code echt uit of hij een indentatie van 2, 4 of 7 spaties gebruikt? Natuurlijk niet! Als hij maar geïndenteerd is.

[Compizfox]

mashell schreef op vrijdag 14 oktober 2016 @ 12:48:
[...]

We ontsporen een beetje van het hoofdtopic.
Ik denk dus niet dat je tabs voor aligment moet gebruiken. Ik denk dat je tabs helemaal nergens anders dan in Microsoft Word zou moeten willen gebruiken (en zelfs daar ben je met een tabel meestal beter af).
Indentation doe je met de tab toets. De levert je (afhankelijk van de coding guidelines 2,3 of 4 spaties) maar nooit een echte tab. Dat zorgt ervoor dat ik, mijn eigen code, in willekeuring welk tool ik wil gebruiken of moet gebruiken (debuggers, compare tools, pcs van collega's) altijd kan herkennen en zonder nadenken over persoonlijke lokale settings kan bewerken. Dat is gewoon veel efficienter werken. Als je in je 1tje een project in alleen Visual studio maakt dan maakt het niet zoveel uit. Maar werk je meerdere mensen aan dezelfde code en gebruik je veel verschillende tools dan maakt het heel erg uit. Als je bijvoorbeeld met git op de commandline een code merge doet is een tab size van 8 (de standaard op een commandline) gewoon erg onhandig.
Als iedereen tabs gebruik gaat het altijd mis omdat niet alle tools dezelfde instellingsmogelijkheden bieden. het belang zit hem dus in het gebruik van dezelfde code in verschillende tools door verschillende mensen op verschillende machines.

Dan begrijpen we elkaar in elk geval wel

Ik ben nog nooit tegengekomen dat je een editor/IDE niet goed kunt instellen voor gebruik van tabs. En juist als je samenwerkt zijn tabs handiger omdat je daarmee niemand dwingt om een bepaalde indentation size te gebruiken, imo. Maar goed, we moeten het hier maar bij laten denk ik

[ Voor 3% gewijzigd door Compizfox op 14-10-2016 20:55 ]

[DJMaze]

Compizfox schreef op vrijdag 14 oktober 2016 @ 13:02:
En juist als je samenwerkt zijn tabs handiger omdat je daarmee niemand verplicht om een bepaalde indentation size te gebruiken

Ik werk aan verschillende projecten in verschillende talen.
Het ene project gebruikt standaard "2 spaties", het andere project "4" spaties en weer een ander "3 spaties".
Moet ik elke keer in mijn editor de "tab to spaces" instelling aanpassen, helemaal handig als je in meerdere projecten tegelijk werkt
Die projecten zijn niet van mij, maar van anderen en die hebben hun "standaard" in welke programmeertaal dan ook.
Ik werk dus soms in Perl, C++, PHP en XML tegelijk.

Ja leuk elke keer die regeltjes in .c, .h, .js, .php, .css, .html, .xml bestanden die aangeven wat de indent "moet" zijn.

Een tab is dus bij mij gewoon een tab en een spatie een spatie.
En het liefst zou ik zien dat elke project gewoon tabs gebruikt, hoef ik niet moeilijk te doen bij elk project met spaties

En van de andere kant begrijp ik het ook: "ik zie graag N spaties, maar mijn editor toont een tab als X spaties en dat kan ik niet aanpassen naar N. Dus tabs mag niet"

P.S. op het web telt elke byte en HTML met tabs is minder bytes dan HTML met spaties.
Ja je kan comprimeren, maar HTML "minify" is een no go. Daarvoor gebruik je gzip/brotli.
En zelfs dit is discutabel omdat netwerk pakketjes N bytes zijn en je echt niet N bytes minder hebt als je tabs gebruikt.

En zo blijft de discussie voort gaan

[ Voor 27% gewijzigd door DJMaze op 14-10-2016 13:45 ]

[CH4OS]

DJMaze schreef op vrijdag 14 oktober 2016 @ 13:25:
Die projecten zijn niet van mij, maar van anderen en die hebben hun "standaard" in welke programmeertaal dan ook.


En het liefst zou ik zien dat elke project gewoon tabs gebruikt, hoef ik niet moeilijk te doen bij elk project met spaties

Met andere woorden, jullie zitten wel in elkaars code te werken, hebben geen afspraken gemaakt over de coding style en vinden de eigen codingstyle heilig (zo komt het althans wel op mij over nu).

Hoe gaat dit werken op de langere termijn, als er bijvoorbeeld collega's erbij komen? Dit lijkt mij althans op een gegeven moment onwerkbaar en zou het daarom bijna amateuristisch willen noemen.

[ Voor 4% gewijzigd door CH4OS op 14-10-2016 13:49 ]

[DJMaze]

CH40S schreef op vrijdag 14 oktober 2016 @ 13:47:
Met andere woorden, jullie zitten wel in elkaars code te werken, hebben geen afspraken gemaakt over de coding style en vinden de eigen codingstyle heilig (zo komt het althans wel op mij over nu).

Ik had misschien even moeten toelichten dat dit niet binnen één bedrijf is, en dan nog...
Als je software sources aankoopt van andere bedrijven ga je die niet ombouwen. Dan zit je weer met patch/merge problemen in de toekomst.

[CH4OS]

DJMaze schreef op vrijdag 14 oktober 2016 @ 13:52:

Dan nog zorg je als collega's onderling voor afspraken over de codestyle, zodat iedereen zich in elk geval daar aan houdt, dat maakt het lezen / interpreteren wat de code doet al een heel stuk makkelijker. Het blijft gissen en als er medewerkers bij komen, wordt die wildgroei alleen maar erger (iedereen heeft immers eigen voorkeuren), maakt niet uit binnen hoeveel bedrijven dat is.

[ Voor 12% gewijzigd door CH4OS op 14-10-2016 14:04 ]

[wartclaes]

DJMaze schreef op vrijdag 14 oktober 2016 @ 13:25:
[...]
Ik werk aan verschillende projecten in verschillende talen.
Het ene project gebruikt standaard "2 spaties", het andere project "4" spaties en weer een ander "3 spaties".
Moet ik elke keer in mijn editor de "tab to spaces" instelling aanpassen, helemaal handig als je in meerdere projecten tegelijk werkt
[...]

Daarvoor is editorconfig wel handig natuurlijk. Dan doet de IDE dat allemaal voor jou en ben je zeker dat alles bij iedereen synchroon loopt.

[bwerg]

mashell schreef op vrijdag 14 oktober 2016 @ 12:48:
Dat zorgt ervoor dat ik, mijn eigen code, in willekeuring welk tool ik wil gebruiken of moet gebruiken (debuggers, compare tools, pcs van collega's) altijd kan herkennen en zonder nadenken over persoonlijke lokale settings kan bewerken.

Betekent dat ook dat jullie font, kleurenschema's, zoomniveaus en window sizes gestandaardiseerd hebben? Dat als de nieuwe developer night-mode aanzet hij word gewezen op de standaarden want nu herken je je code niet meer?

Zonder nadenken bewerken met tabs kan juist heel gemakkelijk. Ik zit nu altijd te klooien of ik één of vier keer backspace moet doen om een indentation met spaties weg te halen.

[ Voor 13% gewijzigd door bwerg op 18-10-2016 11:31 ]

[DJMaze]

bwerg schreef op dinsdag 18 oktober 2016 @ 11:17:
Ik zit nu altijd te klooien of ik één of vier keer backspace moet doen om een indentation met spaties weg te halen.

Daarvoor heb ik in mijn editor de shortcut Shift+Tab. Dan gaat de indent 1 naar links ipv rechts.

[ Voor 8% gewijzigd door DJMaze op 18-10-2016 12:16 ]

[bwerg]

DJMaze schreef op dinsdag 18 oktober 2016 @ 12:16:
[...]

Daarvoor heb ik in mijn editor de shortcut Shift+Tab. Dan gaat de indent 1 naar links ipv rechts.

Dat is wel waar. Al werkt navigeren met links/rechts nog niet altijd even fijn met veel spaties, niet alle editors springen dan ook x spaties verder.

[Pino]

b2vjfvj75gjx7 schreef op donderdag 13 oktober 2016 @ 18:18:
Ook leuk als je variabele van naam verandert en je de boel netjes uitgelijnd wil houden...

code:

$primaryProduct = "Foobar";
$price          = 123.50;
$sku            = "48-a";

En dan bepaalt iets of iemand dat $primaryProduct opeens $mainProduct moet heten;

code:

$mainProduct = "Foobar";
$price       = 123.50;
$sku         = "48-a";

Dan moet je dus ook alle uitlijningen aanpassen (3x in dit geval), omdat het anders niet netjes leest...

Vandaar dat ik gewoon doe;

code:

$primaryProduct = "Foobar";
$price = 123.50;
$sku = "48-a";

...niet mooi - wel effectief

True!

Nog een nadeel, je voegt 1 variabele toe, moet de uitlijning van een heel blok aanpassen, en in je versiebeheersysteem lijkt het dus of je de halve file gewijzigd hebt.

[DJMaze]

Pino schreef op dinsdag 18 oktober 2016 @ 15:36:
en in je versiebeheersysteem lijkt het dus of je de halve file gewijzigd hebt.

Dat is toch ook zo

[mashell]

bwerg schreef op dinsdag 18 oktober 2016 @ 11:17:
[...]

Betekent dat ook dat jullie font, kleurenschema's, zoomniveaus en window sizes gestandaardiseerd hebben? Dat als de nieuwe developer night-mode aanzet hij word gewezen op de standaarden want nu herken je je code niet meer?

Zonder nadenken bewerken met tabs kan juist heel gemakkelijk. Ik zit nu altijd te klooien of ik één of vier keer backspace moet doen om een indentation met spaties weg te halen.

Nee. Er wordt een standaard editor aangewezen (Eclipse bijvoorbeeld). En een standaard "workspace/project" wil je aan andere editor dan mag dat maar de andere mogen daar niets van merken. En dat doe je door code guidelines te gebruiken.

Het probleem met de tabs en spaties zit vooral bij externe debuggers, compare tools en commando regeltools (zoals git). Als iedereen altijd spaties gebruikt gaat dat altijd goed.
Het is gewoon verwarrend als de een functie een andere inspringing heeft dan een andere. Iets wat vaak bij nieuwelingen wel eens voorkomt. Die gebruiken dan tabs. In de editor zie je dat bij een review niet altijd maar in een debugger valt het meteen op.
Bij alle bedrijven waar ik de laatste 15 jaar gewerkt heb waren tabs verboden. Ik heb nog nooit een omgeving gezien waarin tabs wel gebruikt werden.

[.oisyn]

Waanzin . Maar ik ben nog steeds benieuwd naar het antwoord op mijn laatste vraag...

Het is gewoon verwarrend als de een functie een andere inspringing heeft dan een andere

Dat is ook verwarrend. Maar je snapt toch wel dat dat niets te maken heeft met tab-gebruik an sich, maar puur door het mixen ervan? Precies hetzelfde probleem krijg je ook andersom.