- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Valójában "Use the source Luke!" elven igyekszem követni az előző programozó(k) által használt módszert.
- A hozzászóláshoz be kell jelentkezni
Mi az eljárás, ha olyan forrással kerülsz szembe, ahol az egyik fügvény 2 space-es indentálást használ, a másik függvény tab-osat, és véletlenszerűen váltogatják egymást? Mi a helyzet akkor, ha egy függvényen belül hol tab, hol space van? :)
(Takarítottam indiánok után, csak azért merült fel.)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Get dropbox account now!
- A hozzászóláshoz be kell jelentkezni
Akkor bizonyosan nem pythonban kódoltak :-P
- A hozzászóláshoz be kell jelentkezni
Az a megoldás, hogy kijavítod az IDE megfelelő indentálási funkciójával, és úgy kommitolod be a verziókezelőbe.
Ezért szeretem az Eclispe Save Actionjeit, ott beállíthatod, hogy mentéskor indentálja újra a file-t a beállított szabályok szerint.
- A hozzászóláshoz be kell jelentkezni
Horribile dictu: a verziókövető pre-commit hookja is (újra)indentálhatja a kódot.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
3 space
--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)
- A hozzászóláshoz be kell jelentkezni
+1, nem is ertem, hogyan maradhatott ki...
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Sokáig én is 3 space-eztem, csak másokkal való együttműködéskor okozott gondot, ezért lett inkább a 4 space vagy a 4-es tab beosztás. Magamtól 3 space-eznék.
- A hozzászóláshoz be kell jelentkezni
Ezt miért nem kezeli le az IDE/Editor? Azért van a gép, hogy dolgozzon.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Egyéb: leszarom hogy hogyan van megoldva, látszódjon négynek. Többit oldja meg az IDE, azért van.
Egyébként célszerűbbnek találom a tabot, mert azt bárki arra állítja, amire akarja.
Viszont régen Pascal/Delphi alatt 2 karaktert használtam.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
a tabra:
pontosan!
Nem ertem, hogy sok _hulye_ miert nem kepes ezt felfogni?
- A hozzászóláshoz be kell jelentkezni
+1
Itt se ertettem a sok balfaszt:
http://programmers.stackexchange.com/questions/57/tabs-versus-spaces-wh…
kedvencem: cmd+f/ctrl+f es Timwi: mindenhol elmondja ugyanazt a gyokerseget
- A hozzászóláshoz be kell jelentkezni
1, Ha valaki hülye, akkor neki hivatalból szabad nem felfogni.
2, Vagy az elmélet kitalálója ..., és akkor hivatalból nem kell felfogni.
Szóval, ha nem tapasztaltál olyat, nem tudsz róla, akkor kizárt?
Azt kéne felfogni, hogy az élet sosem olyan egyszerű, mint néhány hozzászóló.
Hogy a témához is hozzászóljak, én mindig szóközt használok, és kerülöm a tab-ot. Ami valóban felesleges szabály, ha egy IDE-t használunk, de ez nincs mindig így. Nekem vannak olyan forrásaim, amik régebbiek, mint a jelenleg használt IDE. Van olyan fejállományom, amit használ egy Qt-s GUI (ami ráadásul multiplatform), és egy mikrokontroller C programja, nem ugyan az az IDE. Vannak script-ek is amikhez nem használok IDE-t, csak legalább 4 féle text editort, ami éppen van a gépen. Nincs mindegyik ugyanúgy beállítva, és nem is biztos, hogy értelmezettek mindnél az ilyen jellegű beállítások.
- A hozzászóláshoz be kell jelentkezni
Melyik editort nem lehet beallitani, hogy a kibaszott tabbal mit kezdjen?
Ha az egyik editord nem tudja lekezelni a "_problemat_", akkor balfasz modon valasztottad ki.
Vagy csak teszed a hulyet, vagy csak az is vagy.
- A hozzászóláshoz be kell jelentkezni
És ha lehet állítani, akkor mi-van. A saját gépemen, be szoktam állítgatni editort, IDE-t, de sok géppel van ám dolgom. Az se biztos, hogy azt én állítottam be, vagy én választottam editort, IDE-t. És ekkor sem szeretem, ha bemásolom a szarjaimat, és szétesik az indentálás, ha valamiért bele kell nézni.
Az rendben, hogy ennek nincs jelentősége egy jól belakott környezetben, de mi van, ha ez nem adott. És olyan is van ám, hogy változik a környezet valamiért. Nekem még nem volt abból bajom, ha szóközt használtam, a tabokkal már igen.
Úgy tűnik, nem egyezik a véleményünk, hogy ki teszi a hülyét.
Amúgy pedig a véleményemet írtam le, amit nem muszáj elfogadni, és veled ellentétben emiatt még hülyének sem foglak nézni (a stílus miatt levont következtetéseim pedig nem tartoznak a témához).
- A hozzászóláshoz be kell jelentkezni
a tobbsoros if kifejezest mennyivel huzod beljebb?
csak ezert kerdem mert ha neked tab = 4 spacenek latszik, es ugy "szep" az if, lehet masnal meg ronda lesz, mert o" 2-6-8 space-s tabot hasznal.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
lock
- A hozzászóláshoz be kell jelentkezni
milyen lock te editorhuszar? :D
teljesen igaza van, lehet, hogy ahol nezed (pl code review tool) ott be sem lehet allitani
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
CSS-be: tab-size: 4 - illetve korabban pre {-moz-tab-size: 4;} kellett.
(nalam user css-be kerult be, a review feluleten nem akartak modositani akkor meg)
Ha egy file-on (plane egy soron!) belul van tab es space is, akkor meg szolni kell a gazdinak, hogy tegye tisztaba mielott commitolja. Tobbek kozt errol is szol a review.
Egyebkent pont az eltero szelesseg miatt kerulom a tabot, sajat programban fixen 2 space a behuzas, mas letezo kodjaba meg blend-in elvvel (ahogy az adott file-ban/modulban/projectben van).
{}-nel ugyanez: ha sajat kod, a { es } egymas fole kerul, ha mase, akkor blend-in.
Az, hogy igy szintenkent 1-1 byte-tal nagyobb (1 tab helyett 2 space), nem izgat, tomoritve plane nem.
--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.
- A hozzászóláshoz be kell jelentkezni
"Indent with tabs, align with spaces" elv híve vagyok, szerintem jól működik.
A behúzásnál a tab 1 egység, tök mindegy milyen szélesen jelenik meg, az igazításnál ahol fontos hogy egymás alatt megfelelő pozícióban legyenek tartalmak ott pedig szóköz.
- A hozzászóláshoz be kell jelentkezni
Nem érdekel, rábízom az IDE-re, hogy formázza magától, a beállítás meg az adott projekten, munkahelyen múlik. Visual Studiónak vannak defaultjai, ott pl. C#-ban 4 space (de XML-ben 2 space). Google Java style guide Eclipse-be betöltve 2 space. A tab-bal sincs bajom amúgy, sokáig dolgoztam tab-ra állított Visual Studióval.
- A hozzászóláshoz be kell jelentkezni
De erdekeljen, mert csapatban dolgozol, ahol mindenkinek ugyanugy kene kineznie! Mi van ha valaki 2 valaki 4 valaki meg 8 space-szel indental ugyanabba a forrasfajlba? Azt hogy oldja meg az IDE-d magatol?
(Amugy legyen tab, pont ezert, de erdekeljen akkor is)
- A hozzászóláshoz be kell jelentkezni
Félreértettél. Engem azért nem érdekel, mert az IDE megformázza magától. A csapat összes tagja egyforma IDE beállítást használ. Tehát extra munka nélkül magától ugyanúgy fog kinézni. A csapat többi tagja sem a formázással bajlódik.
Pont akkor lenne baj, ha minden ember kézzel formázgatna. Jobb IDE esetében tab/space nyomogatás sem kell, a { karakter hatására már magától bentebb ugrik a kurzor. Aki cat-tel és hasonlókkal programozik, az persze úgy járt.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+sok
ctrl+a, ctrl-shift-f, és az egész kódot összeformázza az eclipse pont úgy, ahogy a szabályok szerint be van állítva, az összes fejlesztőnél. Kézzel nem identálunk.
- A hozzászóláshoz be kell jelentkezni
De erdekeljen, mert csapatban dolgozol, ahol mindenkinek ugyanugy kene kineznie! [...] (Amugy legyen tab, pont ezert, de erdekeljen akkor is)
Miért, van, ahol a space több spacenek néz ki, vagy mi?
- A hozzászóláshoz be kell jelentkezni
Attól függ. Makefile-ban szerintem megesik az emberrel, hogy a tabot tabnak szeretné meghagyni.
- A hozzászóláshoz be kell jelentkezni
4 space, amúgy láttam már olyan mixet, hogy tab, látszódjon 8-nak, közben meg space-szel pótolva, de maga az indentálás 4.
- A hozzászóláshoz be kell jelentkezni
Legtöbbször mcedit-tel írok scripteket, ott így használom. A TAB billentyű mod 4 = 0-ra pozícionál, viszont minden második ilyen pozíció esetén a tabulátor kódját használja, köztes helyeket szóközökkel egészíti ki. Tehát pl. a 12-es pozíció kezdődik egy tabulátorral, folytatódik 4 szóközzel.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Pythont tanulom, négy space a default behúzás. Miért? Csak. Lehetne tab is, a lényeg, hogy akkor végig, következetesen az legyen.
Mivel vimet használok, így oldottam meg a hordozhatóságot:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
Python template
"""
# vim: tabstop=4 expandtab shiftwidth=4 softtabstop=4
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Csak egyszer kerüljön szerkesztésre a kód olyan editorral, ami space/tab oda-vissza tekerget...
- A hozzászóláshoz be kell jelentkezni
Lássuk be, ez mindenképpen probléma volna. Szerencsére én nem vagyok programozó és nem kell másokkal együtt dolgoznom. De a négy space konkrétan négy space, míg tab, az hol ez, hol az, ahogy épp az adott szövegszerkesztőnek tetszik.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Python-ban igen. Más, értelmes nyelvben (tehát pl. Whitespace pont nem) meg nem gond.
- A hozzászóláshoz be kell jelentkezni
Ott meg van más gond. Nekem a behúzás mint blokk meghatározó szintaktika jobban megfelel, mint a pontosvesszők és kapcsoszárójelek alkalmazása. Igaz, én COBOL-on nőttem fel, ott meg már az se mindegy, hogy melyik oszlopba mit írsz. (ez igazából csak a sorok elejére igaz) Viszont ezzel rákényszerítenek, hogy olvasható kódot gyárts. ( persze még mindig kibaszhatsz a kollegákkal, ha például O00O0, OO00, O0O0, etc... változóneveket használsz :-) )
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Nekem meg komolyabban Fortrant tanítottak elsőre :-P
- A hozzászóláshoz be kell jelentkezni
Akkor minden esélyed megvolt, hogy igazi programozó legyen belőled! :-P :-D
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Ja. De már elmúlt. Rögtön a következő évben, amikor Pascal-lal folytatuk :-P
- A hozzászóláshoz be kell jelentkezni
Jé. Épp ilyen sanyarú sorsom volt nekem is.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Soósferi?
- A hozzászóláshoz be kell jelentkezni
Meg nem mondom. BME-n követte el valaki ezt a merényletet a '90-es évek elején.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Akkor nem. Illetve NME :-)
- A hozzászóláshoz be kell jelentkezni
Teljesen mindegy.
Leginkabb tab, aztan ki hogy allitja be, hogy az mekkora behuzas.
Space(ek) is lehetnek, amig jol atlathato, nem ezen fog mulni.
- A hozzászóláshoz be kell jelentkezni
Lazan kapcsolodik, de hatha tud ra valaki megoldast: azt az egyszeru, ugyanakkor zsenialis Emacs feature-t szeretnem tetszoleges IDE-ben (pl. Eclipse, IDEA) latni, hogy a TAB lenyomasara a sort automatikusan indentalja, _akarhol allok a soron belul_.
- A hozzászóláshoz be kell jelentkezni
eclipse-ben a correct indentation-t tab-ra rakod (a tab beszurast meg control-i-re)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Ez jo, koszi, sajnos Pythonnal egyaltalan nem mukodik, Scalaval meg nagyon fapadosan (nem jol indentalja a pattern matchet pl.). Igaz, a beallitas szerint "When: editing Java Source", hiaba allitom at Scalara, nem lesz tole okosabb :)
- A hozzászóláshoz be kell jelentkezni
Ideaban Cmd+Shift+Enter (Complete current statement) vagy Ctrl+Alt+I (Auto-indent line(s))
- A hozzászóláshoz be kell jelentkezni
PyCharm-ban probaltam: Ctrl-Shift-Enter semmit nem csinal, azon kivul, hogy uj sort nyit es odaugrik (Linuxon ez a Complete current statement). Az auto-indent pedig kisse eklektikus, igaz, pont Pythonban siman nem egyertelmu, hogy mire gondolt a kolto, ha nincs rendesen indentalva, de mondjuk ismetelt nyomogatasra esetleg valtogathatna az alternativ megoldasok kozott. Becsszo, nem kotozkodni akarok ;)
- A hozzászóláshoz be kell jelentkezni
Szerintem a fent említett parancsok nem azt csinálják, amit te akarsz, szóval nem benned a hiba.
Ellenben, de nem szép megoldás: ha kijelölsz akár egy betűt, s úgy ütsz TAB-ot, akkor beljebb húzza a sort.
--
blogom
- A hozzászóláshoz be kell jelentkezni
Ez sajnos meg kevesbe segit, mint az autoindent, csak berak vagy elvesz egy tabot a sor elejerol... de az otlet nem rossz :)
- A hozzászóláshoz be kell jelentkezni
ah. félteértettelek, bocsi.
--
blogom
- A hozzászóláshoz be kell jelentkezni
Én Ideat irtam, nem PyCharm-ot :)
- A hozzászóláshoz be kell jelentkezni
Csak kovesse az eloirtakat projekten belul. Peldaul Magento: 4 space, es meg az is meg van hatarozva, hol lehet az if utan a zarojel vagy a kezdo curly bracket.
Drupal: 2 space, nagybetus TRUE, stb.
Amikor meg valaki ezeket nem veszi figyelembe, nagyon ki tudok akadni. Kedvencem, amikor az IDE defaultja belekever tabokat a space-ba.
Vagy amikor a tab nem eleg egy array() belo elemeinek indentalasara, es a hgy space-el kipotolja, amit a tab nyomkodasa nem old meg...
Javaslom, hogy mindenki telepitse es hasznalja az editorconfigot a sajat szerkesztojehez:
Sajat projekteken belul 4 space-t hasznalok, mert csak. Szoval arra szavaztam.
- A hozzászóláshoz be kell jelentkezni
Meg jobb helyeken meg írnak a nyelvhez ajánlást.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
tab látsszon 3 space-nek
- A hozzászóláshoz be kell jelentkezni
https://www.drupal.org/coding-standards
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
Már a kérdés maga megmutatja, hogy a tabozás problémát tud okozni. Mit értünk azon, hogy "látsszon"???
A Pisti vimjében? Vagy a Joli eclipse-ében? Githubon? Ha sehol nem használsz igazításhoz space-t, akkor rendben is van. De ha előfordul ilyen:
int MyLittleMethod(int first, int second, float third, void* fourth,
int pooorFifthWrappedToSecondLine) {
// ...
Akkor cseszheted a tabjaidat. És rengeteg forráskód íródik így. A safe opció: space.
Haskellnél, pythonnál importkor jól tud jönni a tabuláris szerkesztés. Itt egy példa:
import qualified Data.ByteString.Char8 as SBC
import qualified Data.HashMap.Strict as HMS
import Data.List (isInfixOf)
import Data.Monoid ((<>))
import qualified Data.Text as T
import qualified Data.ByteString as S
Egyből látod, milyen függőségek vannak. Néha persze leszarom, mert OrganizeImports azt szevasz, de ez nem mindig opció.
Nemcsak importkor jön jól, ha van block editing az editorban. Segít kiszűrni a hibákat is. Sajnos bár léteznek jobb megoldások, bizonyára mindenki belefutott már ilyesmibe:
if (myVar2 < 3 && myOtherVar == OK) { doThreeThis(); }
else if (myVar1 < 5) { doFiveThis(); }
else if (myVar1 < 100) { doHundredThis(); }
else if (myVar1 < 1000*1000) { doThreeThis(); }
Látod a két hibát? Persze, hogy nem. Próbáld meg így:
if (myVar2 < 3 && myThreeVar == OK) { doThreeThis(); }
else if (myVar1 < 5) { doFiveThis(); }
else if (myVar1 < 100000) { doThousandThis(); }
else if (myVar1 < 1000*1000) { doThreeThis(); }
Egyből kiszúrod, hogy véletlenül egy helyen myVar2-t írsz myVar1 helyett. Illetve doMillionThis helyett is doThreeThis lett. Ezek szemantikai hibák, nincs az az editor, ami figyelmeztetne (btw. de van, de ez offtopik). Megjegyzés: tudom, hogy ez nem a legszebb kód. De nem mindig te írod a kódot, néha kapod, és a git commitban nem akarsz stílust javítani egy bugfixért ugyebár.
Hogy fair legyek: van ennek is drawbackje:
1) szar editorban nem tudsz blokkosan szerkeszteni. Megoldás: normális editor.
2) verziókezelőben nemcsak a fentihez hozzáadott egy sor, hanem a hozzáigazítás miatt a többi is változhat (csak whitespace-ek). Megoldás:
git diff -w
Tabuláris szerkesztéskor tehát egyetlen opció: space.
Sok projektben megvan adva maximum kódszélesség. És ha tabozol? Akkor a 120 karakteres jobb határ az 4 karakteres, vagy 2, vagy 3, vagy esetleg 8 karakteres tabra van kitalálva?
A mindenhol konzisztens opció: space.
A tabozásnak egy modern editorban már nincs semmi előnye. Példa: A tab 8-ra van állítva, már gépeltem két karaktert, lenyomom a tabot, beilleszt 6 karaktert. Ha unindentálni akarok, tabszélesség egységenként tudom ezt is tenni. De ha még át is akarok térni tabokra, vagy vissza space-ekre: retab.
Hátránya viszont annál több, mint azt láthattuk a fenti példákban.
Ahogy előttem is írták, kövessük a projektben meghatározott style guide-ot. Ezzel értek egyet leginkább. Főleg, ha valamilyen okos módon (pl. vim-ben modeline vagy exrc, máshol esetleg EditorConfig) be is van tartatva.
Van olyan projektem, ahol vígan space-ezek (és van hozzá modeline is, tehát véletlenül sem tudom nem betartani). Természetesen a Tab leütése nálam is 2,4 space-t, vagy \t karaktert szúr be. Ugyanígy az (un)indent 2,4 spacet, vagy \t-ot ad hozzá/vesz el.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
> Van olyan projektem, ahol vígan space-ezek
Szorri, arra gondoltam, van olyan, ahol vígan tabozok.
- A hozzászóláshoz be kell jelentkezni
A fenti kódrészletekkel egy baj van. Azt mondod, hogy az egyes elemekre tekintsünk úgy, mint egy táblázatra és a következő oszlopok indulási pozícióra igazodjon az aktuális oszlop legszélesebb oszlopához.
Na de mi van akkor, ha ezt oszlopot törlöd, mert nem kell? Vagy éppen átírod és már nem az lesz a leghosszabb? A többi kódrészt is újraindentálod? Szép dolog, csak elrontja a diff-et: olyan sorok is változnak, amelyek egyébként funkcionálisan nem módosultak. Oké, hogy a git tudja mutatni a diff-et whitespace-ek nélkül, de erre nem lehet támaszkodni: nem használni mindenki git-et és a code review eszközök sem mindig támogatják.
Én pont ezért szoktam le róla.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
Leírtam, hogy lehet hátulütője. Azt is, hogy mi a megoldás. Ahogy te is.
Szerintem inkább a diff "romoljon el". Ha a diffre ránézel (git esetén -w nélkül), akkor is látható, hogy space change volt csak, és vizuálisan ki tud bukni ha hiba van. Ezt az "elromlott" diff-et két-három ember látja (a committer, és a reviewerek mondjuk), míg magát a kódot aztán 1-től 10-en át (projekttagok esetén) 100-on át (osztott lib esetén) milliókig (nyílt forrás esetén) mindenki.
Tényleg három-négy ember miatt lemondanál a többiekről? Ráadásul úgy, hogy hármuknak bár pár sorral több lesz a diff, de továbbra is vizuálisan konzisztens marad...? Érdekes.
Az ember felismer alakokat, összetételeket (ezáltal szavakat, változó- és függvényneveket), viszont amiben ezeszer jobb, már a szem is, az a különbségek felismerése. Nem véletlenül használunk táblázatokat több ezer éve. Én azt vallom, hogy ha már van szemünk és agyunk, használjuk. Ha már használjuk, használjuk hatékonyan. Miért pont kódoláskor ne? :-)
Ha jobban el szeretnél mélyedni a témában, ajánlom az ide vonatkozó irodalmat a vizuális érzékelésről. Meglepő, mennyi új dolgot tanul az ember már az első két bekezdéséből egy-egy ilyen könyvnek. (Én személy szerint ezt forgattam: http://www.amazon.com/Applied-Security-Visualization-Raffael-Marty/dp/0…)
- A hozzászóláshoz be kell jelentkezni
Én is a space-ekre szavazok. Ugyanakkor szerintem a programozás nem rajzművészet, nem ilyen szempontból kell "szépnek" lennie. Az ilyen elrendezés szerintem pont nem szép, de ezen mondjuk lehet vitázni. Az alapvető hibák kiszűrésére unit tesz kell.
- A hozzászóláshoz be kell jelentkezni
Egyrészt az sosem baj, ha szép.
Másrészt nem a szépségen volt a hangsúly.
> Az alapvető hibák kiszűrésére unit tesz kell.
Mivel már így is sokat írogattam ide, ezért most rád bíznám a feladatot: keress statisztikákat légy szíves, a ma használatban levő szoftverek (szűkítsük mondjuk nyílt forrásúakra) össz-unitteszt-coverage-ére. :-)
Az, hogy van egy - sajnos alig használt - eszköz a hibák kiszűrésére, nem jelenti azt, hogy ne használjunk másik jó eszközt :-)
Lásd még: yoda conditions.
- A hozzászóláshoz be kell jelentkezni
A Yoda conditions a C erőszakolása egy kicsit biztonságosabb irányba, de messze nem "jó eszköz".
--
blogom
- A hozzászóláshoz be kell jelentkezni
Igaz. De jobb, mintha nem lenne.
- A hozzászóláshoz be kell jelentkezni
Attól, hogy sok szoftverhez nincs teszt, nem jelenti azt, hogy ez jó, még kevésbé azt, hogy ezt kellene elfogadni követendő példaként. Erre a problémára a blokkos kódformázás maximum placebo, és sokkal kevésbé hatékony, mint egy jól megírt unit teszt. Úgy értem, sokkal kevesebb esetben van előnye a nem blokkos formázáshoz képest. Egyébként a nem konzekvensen elnevezett metódusok, vagy a var1/var2 jellegű változónevek, amik az eredeti példában vannak, eleve kibuknak egy code review-n. Tudom, a ma használatban levő szoftvereknél ez sem feltétlenül jellemző :).
- A hozzászóláshoz be kell jelentkezni
Amiket leirtal igazak, csak nem relevansak. Ha megfeszulsz, akkor sem fogja a developer vilag a unittesztjeidet irogatni, meg kevesbe kodreview-zni. Nezz korul githubon.
Mielott leirnad, hogy dehat ez igy nem jo, meg egy normalis projektben ez aztan nem igy van, meg te aztan nem csinalnal ilyet, meg kulonbenis... Inkabb meg egyszer elmondom: nem az a kerdes, mi az utopikus alomvilagban a jo, hanem az, hogy mi van eppen.
Es az van, hogy hiaba volt meg a kodreview, hiaba volt ott a unitteszt, mivel a ket reviewer eppen felalomban volt hatarido elott, ezert csak ott maradt a release-ben a var1/2.
A masik esetben a unitteszt meg eppen atlepte a szemantikai problemat, merthiszen a policy az, hogy 92%-os coverage felett mar jok vagyunk.
Mielott leirnad, hogy akkor a business processzekkel meg a reviewerekkel meg a managerekkel meg a joegtudja meg kivel van gond, inkabb leirom en: igazad van, de ettol meg EZ VAN.
- A hozzászóláshoz be kell jelentkezni
Értem én, hogy ez van, de attól ez még a valóságnak csak egy szelete. Lehet csak nekem volt szerencsém, de eddig olyan helyeken dolgoztam, ahol sokat számít a kód minősége, kötelező review és coverage van.
Ugyanakkor te is javasolsz egy bizonyos kód formázási módszert, de ugyanúgy kétséges, hogy ez van, vagy nem ez van.
Másképpen fogalmazva, mindkettő módszert lehet használni vagy nem használni és tákolt kódot írni. Én csak annyit állítok, hogy ha valaki igényes kódot akar írni, inkább unit tesztet írjon a maradék idejében. Ha nem akar, akkor meg úgyis mindegy.
- A hozzászóláshoz be kell jelentkezni
Akkor te még nem használtál Python-t... Ott kötelező rajzművészet van :-D
- A hozzászóláshoz be kell jelentkezni
PEP 8 meg a rajztanár. :)
- A hozzászóláshoz be kell jelentkezni
A beteges Python fóbiádra gyógyír lehet a Python3-ra való áttérés :)
https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Nem fóbia, csak hülyeségnek tartom azt, hogy a whitespace releváns része a kódnak...
- A hozzászóláshoz be kell jelentkezni
Csak annyira, mint a C-ben a {} jelek.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
Meg a pontosvessző...
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Inkább a ; mint a "\n" legyen a határoló...
- A hozzászóláshoz be kell jelentkezni
pedig az minden sor végén ott van...
- A hozzászóláshoz be kell jelentkezni
épp azért nem szerencsés, hogy hol csak esztétikum miatt van ott, hol meg jelentéssel bír.
- A hozzászóláshoz be kell jelentkezni
Nagyon kevés nyelvet "ismerek", melyik viselkedik így?
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
JavaScript-ben például nem kötelező a pontosvessző. Elég furcsa is amúgy.
- A hozzászóláshoz be kell jelentkezni
Swiftben sem pl.
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
Van ilyen egyébként, de arra próbáltam reagálni, hogy azt mondtad, inkább legyen a \n a határoló, mert az minden sor végén ott van. És azt próbáltam mondani, hogy épp azért, mert egyébként is ott van minden sor végén -- mert a kóder üti hogy "tipográfiai" szempontból (értsd jól) szép legyen -- ezért nem szerencsés nyelvszintaktikai határolónak, mert akkor hol ez hol az, ellentétben a ;-vel, ami meg akkor van ott, mikor határolót akarsz. Szerintem zeller is ezért mondta, de aztán lehet valamit félreértek :)
- A hozzászóláshoz be kell jelentkezni
A teszt nem a hibak kiszuresere van. A teszt arra van, hogy ellenorizzuk, az adott kodreszlet adott bemenetre adott kimenetet produkal-e, semmi tobbre. Hogy mennyire hibas, mennyire nem hatekony, mennyire lassu - ezt a tesztek merni nem tudjak.
A temaban ajanlott irodalom: http://csakatesztemenkeresztul.blog.hu/2011/10/04/a_teszteles_nem_minde…
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
+1
Régebben azon a véleményen voltam, hogy TAB ott, ahol logikai tabulásásról van szó (ha úgy tetszik: az egymásba ágyazott kapcsos zárójelek számának megfelelően), és szigorúan csak sor elején használható; viszont a MyLittleMethod-os példádnál szóközök. És ennek megfelelően helyenként pedig jópár TAB után csomó (egy TAB-nyinál bőven több) szóköz. Másképp megfogalmazva: a forráskód tetszőleges TAB szélesség mellett nézzen ki helyesen. (De ezzel még mindig van elvi probléma, ahogy mondod, ha be kell tartani egy jobb margót.)
Az egyik nagy probléma ezzel az, hogy gyakorlatilag tarthatatlan, nehézkes.
Jópár éve viszont már azon az állásponton vagyok, hogy a TAB karakter a legtöbb vezérlő karakterhez képest nem való arra, hogy szövegfájlban tároljuk el, mint ahogyan például backspace vagy form feed karaktert sem használunk erre.
Sima szövegfájlban összesen két vezérlő karakter szokott gyakran előfordulni, az újsor (és most a CR kontra LF őrületbe se menjünk bele, az is katasztrófa) és a TAB. Namost ezekből az előbbi szükséges, a második viszont teljesen fölösleges.
A TAB kábé úgy viszonyul a szóközhöz, mint ahogyan a mostanra szerencsére gyakorlatilag kihalt FF (form feed, ^L) az újsorhoz. Metódus végére sem tesz senki manapság FF-et, és kezd el azon filózni, hogy (a TAB-szélességhez hasonlóan) a FF-et ki hány újsorra állítja be saját preferenciája szerint.
A szövegfájlnak nem a dokumentum logikai struktúrájának leírása a cél. Olyan karakter sincs, ami egy nyitó kapcsos zárójel akár a sor végén, akár a következő sor elején, a beállított preferenciák szerint. Olyan sincs, ami függvény neve után nyitó zárójel, szóközzel vagy anélkül a felhasználó ízlése szerint. Olyan sincs, ami függvényeket, osztályokat stb. választana el egymástól, konfigurálható méretű vizuális kihagyással. Miért pont a vízszintes tabulálásra kellene hogy létezzen?
A szövegfájlnak az a feladata, hogy az írógéppel leírthoz hasonlóan a konkrét tartalmat és konkrét kinézetet rögzítse.
És mint ilyen, a TAB billentyű létezése és megfelelő ASCII kód továbbításának lehetősége különféle csatornákon (pl. ssh) egészen odáig hogy elérkezik egy szövegszerkesztőig amelyik ezt látván mindenféle okosságot csinál, teljesen rendben van. De a fájlban eltárolása hatalmas indokolatlan tévedés, melybe a számítástechnika sajnos belefutott a fejlődése során és sajnos nem tud / nem akar levetkőzni.
- A hozzászóláshoz be kell jelentkezni
Egyetértek veled, tetszik, ahogy metaszintre emelted az egész TAB-kérdést :) ("a TAB karakter a legtöbb vezérlő karakterhez képest nem való arra, hogy szövegfájlban tároljuk el, mint ahogyan például backspace vagy form feed karaktert sem")
Ahogy az utolsó bekezdésedben írtad, maradjunk reálisak: lesznek még tabbal indentált kódok, amibe kell contribolnunk. Én teljesen elégedett vagyok az editor segítségével. Ugyanakkor látom, hogy pár kevésbé skilles egyén elcseszi, mert csak beleindentál egy-egy ifnél space-szel, de persze rossz tabmérettel. :-(
- A hozzászóláshoz be kell jelentkezni
Amit itt az if-fel/else%20iffel csinalsz az ugy eleve hogy nez mar ki?
Elegtelen.
- A hozzászóláshoz be kell jelentkezni
Vitakultúra.
Elégtelen.
- A hozzászóláshoz be kell jelentkezni
egyeb: c/c++ 4space, ruby/lua/livescript/scala 2 space
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Cobolban mennyi? (az is c betuvel kezdodik)
--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.
- A hozzászóláshoz be kell jelentkezni
1 tab lenyomás szúrjon be 4 space-t!
- A hozzászóláshoz be kell jelentkezni
A tab nem ennyi-annyi space, hanem a következő: Megadunk egy monoton növekvő sorozatot (ennek elemei a tab-pozíciók), az első elem pozitív, a növekmény ízlés szerinti, és nem feltétlenül egyforma. A tab karakter arra ad utasítást, hogy az írás az aktuális pozíciótól jobbra eső legközelebbi tab-pozíciónál folytatódjon.
Zagyva dolog, kár volt meghonosítani az informatikában.
--
ulysses.co.hu
- A hozzászóláshoz be kell jelentkezni
-1
- A hozzászóláshoz be kell jelentkezni
Ő biztos az utolsó opciót választotta (legalábbis remélem :) )
- A hozzászóláshoz be kell jelentkezni
Olvassatok, és akkor nem tűntök ostobának.
mrevnek igaza van, az írógép tab billentyűje a beállított ún. tab stop-oknál állt meg. Wikipedia:tab stop.
- A hozzászóláshoz be kell jelentkezni
Így van. Speciel ha terminál emulátorban írsz ki egy tab-ot, az csak a kurzort mozgatja, de ha esetleg volt alatta korábban már valami tartalom, azt békénhagyja. (Tehát: kurzormozgató vezérlőkarakter, nem pedig valahány szóköz.)
- A hozzászóláshoz be kell jelentkezni
Es az megvan, balfaszok, hogy nem monospace-t hasznalunk az editorban, hanem proporcionalis fontot.
Ha valaki nem erti, hogy miert jo proporcionalis fonttal dolgozni, akkor az balfasz?
Nem, csak szimplan hulye hozza; ettol meg tud programozni, csak nem erti, hogy lehet monospace helyett proporcionalist hasznalni, es jobb, mert
CSAK; most minek magyarazzam. Ha ezt magayrazni kell, akkor felesleges magyarazni. Ez ertheto, marmint az indoklas? Nem? Jo. (pont, nem felkialto jel)
Megyek kakilni; most kell. (nincs osszefugges, a fentiekkel, most jott meg.)
- A hozzászóláshoz be kell jelentkezni
lock
- A hozzászóláshoz be kell jelentkezni
unlock
- A hozzászóláshoz be kell jelentkezni
relock
- A hozzászóláshoz be kell jelentkezni
Lazan kapcsolodik: http://input.fontbureau.com/info/
Ma ezzel dolgozok, minjart kiderul, mennyire szeretheto :)
- A hozzászóláshoz be kell jelentkezni
Rábízom az IDLE-re és az Emacs-re.
- A hozzászóláshoz be kell jelentkezni
Projekt függő.
A sajátoknál 4 space, Drupal moduloknál a coding standard alapján 2 space, volt munkahelyemen pedig 1 tab volt.
Még szerencse, hogy a NetBeans projektenként külön is konfigurálható.
- A hozzászóláshoz be kell jelentkezni
Forráskódtól függ
- JavaScript, HTML, Python 4 space méretű tab
- (C|L|SC)SS, CoffeScript 2 space
Mindez .editorconfig tárolva, amit elvileg a legtöbb IDE ismer
- A hozzászóláshoz be kell jelentkezni
Pont html-nel space-elsz tab helyett, ahol pont nem mindegy, hogy hany bajt megy ki a kleinsnek? :(
- A hozzászóláshoz be kell jelentkezni
Wtf. Gzipnel nem mindegy hany ugyanolyan karaktert tomorit?
Wtf. Nincs grunt taskban valami minimizer?
Ó. :'-(
Hogy is mondtad? Elegtelen.
- A hozzászóláshoz be kell jelentkezni
Hja, kódtömörítés. Múltkor felfedeztem, hogy JavaScriptben igazából nem kellenek a sorvégi ; -k (ami tök jó, C#-ból, Javaból és minden hasonló syntaxú nyelvből is írtanám ki a francba, teljesen felesleges, ha egy sorban egy kifejezés van).
Mondom ez tök jó, .js fájlok tömörítését is mennyivel egyszerűbben le lehetne tudni így, hogy többé-kevésbé olvasható marad a kód, így egyszerűbb debugolni és nem kell mindenféle mappal szerencsétlenkedni. Erre valaki IRC-en meg akart győzni, hogy de az nem jó, mert úgy nem olyan tömör a kód. Csak tudnám mitől nem, hogy ha a ';' és a '\n' is egy byte...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Akkor neked is baratod lesz a swift.
Mellesleg pont a Safariban lattam eloszor, hogy a minify-olt js-t unminify-olva dobta eled az inspector, az tokre tetszett.
- A hozzászóláshoz be kell jelentkezni
Marmint automatikusan beindentalta vagy valami code map alapjan az eredetit? (Elvileg az IE es a Firefox tudja az utóbbit, Chrome/Webkitre most nem emlékszem).
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Igen, pontosan azt. Chrome ha tudja is, par honapja meg tuti nem adta ugy by default megnyitva a JS source-ot.
- A hozzászóláshoz be kell jelentkezni
"ami tök jó, C#-ból, Javaból és minden hasonló syntaxú nyelvből is írtanám ki a francba, teljesen felesleges, ha egy sorban egy kifejezés van"
Most komolyan? Vagy csak nem éreztem az iróniát így kora reggel?
- A hozzászóláshoz be kell jelentkezni
Milyen plusz információt hordoz a ; szerinted"
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ilyen alapon nem kell curly brace sem, úgyis indentálod a kódod.
Sőt, az if/while feltétele köré sem kell két zárójel, elég a végén valami delimiter, mondjuk kettőspont.
Hopp, és elérkeztünk a pythonhoz. :-)
(Nem, én nem szeretem a pythont)
- A hozzászóláshoz be kell jelentkezni
Ezt hivjak csúszós lejtőnek :)
Amúgy valóban felesleges a () az if/whilenél. A {} már kevésbé hacsak nem akarsz end [if]-eket írogatni, mert a Python indentalashoz kötöttsége szerintem is zavaró tud lenni.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"a Python indentalashoz kötöttsége szerintem is zavaró tud lenni" Yesss, ezexerint nem vagyok ezzel egyedül :-D
- A hozzászóláshoz be kell jelentkezni
Lehetőséget ad multi line statementek írására, ami nélkül valljuk be, a java szörnyen olvashatatlan lenne sok esetben. JavaScript is fordításkor odateszi a pontosvesszőt, ahová te nem tetted, pedig kellett volna.
- A hozzászóláshoz be kell jelentkezni
"Lehetőséget ad multi line statementek írására, ami nélkül valljuk be, a java szörnyen olvashatatlan lenne sok esetben. "
...és? Nehéz számolni a nyitó-csukó zárójeleket egy szoftvernek?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Hogy jön ide a zárójel és a szoftver? Multiline statementekról beszéltem.
- A hozzászóláshoz be kell jelentkezni
És azt szerinted lehetetlen megállapítani, hogy az adott sor végén vagy a következő elején egy operátor van? Pl.
String foo = "asdf"
+ "jklé";
(Mondjuk stringek esetén pont nem lenne ezzel probléma, ha lenne normális multiline string, amit még PHP-ben is képesek voltak megoldani...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Azert ez annyira nem igaz. A multi line statementek nem a pontosvesszo nelkul lesznek olvashatatlanok, hanem a szar indentalasnak koszonhetoen. A pontosvesszo ehhez semmit nem ad hozza.
Raadasul azt gondolom, hogy ha Ruby-nal meg tudtak oldani azt, hogy pontosvesszo nelkul tudok multiline statementeket irni ugy, hogy raadasul ott meg zarojelezni se kotelezo, akkor az osszes C-like nyelv is meg tudna ezt oldani. Csak hat persze a szep hagyomanyok...
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Azért csak óvatosan :)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
SEU-t használok, nincs tab karakter. Ha van egyáltalán értelme a behúzásnak (free rpg), akkor 3 szóközt használok.
C, java, xml, html, stb. kódra ctrl-shift-f, és nem zavar ha a diff csúnya. Mindenki használja ugyanolyan beállításokkal a kódformázót.
- A hozzászóláshoz be kell jelentkezni
A TAB definíciója annó az volt, hogy a következő (8k+1)-ik pozícióra menjen a kurzor (1, 17, 25, 33 stb). Tehát 1-8 szóközzel egyenértékű, a pillanatnyi pozíciótól függően.
Nos, azóta eltelt ötven év, azóta rájöttünk, hogy a szabványok akadályozzák a kreativitást, ezért most minden Hátulgombolós Pistike azt állít be a szövegszerkesztőjében, amit akar. Éljen!
- A hozzászóláshoz be kell jelentkezni
+9
:)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
tab ("\t") - leszarom hány space-nek látszik, 2-nél azért több legyen, de ne legyen félképernyőnyi
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
- A hozzászóláshoz be kell jelentkezni
0 db bármilyen karakter :P
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
- A hozzászóláshoz be kell jelentkezni
Kimaradt a 0 space, ami fontos a kezdő programozók kódjának identálásához :D ;)
- A hozzászóláshoz be kell jelentkezni
Ez egyebkent egy erdekes kérdés, szoftverfejlesztesben rengeteg konvencioval találkozhat az ember, legyen az indentalas vagy nevezéktan vagy akar best practicles. Es azert sokan tanulnak konyvbol, ahol azert jellemzően indentalt kod van. Ennek ellenere megis sokan annyira érzéketlenek, hogy az ilyet észrevegyék.
Másrészről meg zx spectrumon nem volt indentalas basicben :P Pascalban meg átvettem a könyvből, amibol tanultam.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Én találkoztam olyan emberrel, aki könyvből tanult programozni, és kérdezte, hol lehet a kulcsszavakat a megfelelő színűre színezni :-)
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
:D
- A hozzászóláshoz be kell jelentkezni
Miért nem mondtad neki, hogy vim-mel mossa ki a kódot :-D
- A hozzászóláshoz be kell jelentkezni
Nyelvfuggo, minden nyelvnek megvannak a konvencionalis standardjai, igyekszem kovetni. Pythonban, C-like nyelvekben (PHP, Perl, C, C++. C#, CSS, JS, stb.), XML-szeru nyelvekben (XML, HTML) valamint VB.NET-ben 4 space, mindenhol masutt ket space. De ha mas indentalasu koddal dolgozok, akkor igyekszem igazodni az elottem kodolohoz, kiveve, ha ez nem lehetseges az otletszeru indentalasok miatt, ilyenkor astyle-lal atformazom az erintett kodot (amugy is biztonsagi mentek elotte), es tajekoztatom a fejlesztot, hogy mi lett az uj style, es hogy tartsa be, ha azt akarja, hogy segitsek neki a tovabbiakban is.
Sajnos az astyle meg mindig nem eleg okos (bizonyos PHP-s nyelvi konstrukciok komoly fejtorest okoznak neki), de a POSIX-os indent-et sose szerettem, szamomra bonyolult.
A TAB-os kodokat nem szeretem annyira, mert en neha csak cat-tal kinyomok egy kodot, es a konzolon bizony 1 TAB = 8 space, es onnantol nehez olvasni. A space az egy konkret dolog. What you see is what you get.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
van rá magyar szó: behúzás
- A hozzászóláshoz be kell jelentkezni
Te meg egy boxolotol erdemelnel egy nagy behuzast, ha eroltetsz itt ilyen izzadsagszagu eroltetetten forditott kifejezeseket, raadasul ellenzed, ha valaki helyette az angol eredetut hasznalna szivesen ebben a nemzetkozi szakmaban.
- A hozzászóláshoz be kell jelentkezni
Pedig ezt a kifejezést régóta használják rá a nyomdaiparban is. Ennyit az izzadtságszagú erőltetetten fordított kifejezésekről.
Ui.: A billentyűzetet billentyűzetnek hívod? :)
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
Hagyd. Ha végignézed a topikot, mindenhol betrollkodott valami ostobaságot, de alátámasztani nem tudta sehol.
- A hozzászóláshoz be kell jelentkezni
Miert nem sminkeled a Drupal keretrendszerre epulo tartalomkezelo-rendszeredet inkabb? :-)
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Majd az üzemeltető macik. :)
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
Mi nem foglalkozunk sminkelessel, de nagyon szivesen ujratelepitjuk a gepedet.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
A programnyelv amiben dolgozok - mellesleg elég C szerû - gyakran tartalmaz Oracle query-ket, ezért a tab nálam ki van zárva, azzal képtelenség több száz soros selectet értelmesen indentálni. A két space mellett azért döntöttünk, mert vertikálisan szeretjük olvasni a kódot, és habár optimális esetben egy függvény egy dolgot csinál, van egy-két komolyabbnak mondható (relatív) algoritmus ahol elszállt a ló.
Java-ban és javascript esetében TAB és K&R.
- A hozzászóláshoz be kell jelentkezni