Szerintem a legjobb Python indentálás/bekezdés ...

Programozás

A PEP 8 4 space-t ajánl, de ezt most hagyjuk, neked melyik indentálás tetszik a legjobban?

1 space
1% (6 szavazat)
2 space
17% (143 szavazat)
3 space
2% (15 szavazat)
4 space
37% (305 szavazat)
5 vagy több space
1% (10 szavazat)
1 tab
27% (225 szavazat)
2 vagy több tab
1% (9 szavazat)
valami más (hozzászólásban leírom)
1% (9 szavazat)
nem tudom / nem értek a kígyókhoz
13% (112 szavazat)
Összes szavazat: 834

( apal v | 2022. 04. 17., v – 10:27 )

... az amelyik akkor is mukodik ha elkuldenem masnak a kodot... :) meghat vegulis whitespace-ban is lehet programozni de minek.

( arpi_esp v | 2022. 04. 17., v – 11:03 )

AS - ahogy sikerul... random, 1-2-4 space... neha 1-1 tab is bar az mar csak py2-nel mukodott vegyesen

( bithalver | 2022. 04. 17., v – 13:31 )

Meg mindig nem tudtam napirendre terni afelett, hogy a programozok nincsenek kiakadva egy olyan program nyelven, ahol a whitespace a syntax resze ... (leszamitva persze a mar emlitett 'whitespace' programnyelvet ;) )

Vannak a szintaxisaban ennel zavarobb dolgok is. Peldaul az, hogy ki kell tenni a kettospontot (lehetne inkabb zarojelezni), vagy hogy OO-ban ki kell irnod mindenutt a self-et. A tab-okat is tiltanam belole. A space-es behuzas eleinte fura volt, most mar kifejezetten tetszik benne. A C-s && es || meg a ++ es --is kicsivel jobb lenne, de mar megszoktam, hogy nincs. A nyelv (ill. az implementaciok) legnagyobb hatranyanak meg mindig a GIL-t latom, de idorol idore felroppen a hir, hogy dolgoznak rajta, talan megoldjak.

A strange game. The only winning move is not to play. How about a nice game of chess?

Pedig nem olyan furcsa ez. Ha a kedvenc nyelveden ugy kell olvasnod egy kodot hogy nincenek benne bekezdo white space-ek az rendben van? Mert ha nehezebb igy olvasni, akokr ez a konvencio tulajdonkeppen azelott is a syntax resze volt. DE amiert en igazan szeretem, az az, hogy a kodblokkot zaro zarojeleket igy el lehet hagyni (ahogy nyito zarojel sincs). Ugyanezert szeretem jobban a yaml-t a json-nal, jobban olvashato.

Tobb ok miatt is.

1. Kb. nem is tudok olyan projektet, ahol nem jott valami okostojas, es nekiallt ezen a 'color of the bikeshed' teman csamcsogni. Uuuuuncsi! -> kvazi szabvanyositottak legtobb helyen, pl. java ecosystem, de rust is a cargo fmt -vel.

2. Alapvetoen a whitespace disz, es a blokkokat kulon kell jelolni. ez gaz. nekem nagyon tetszik a python-ban, hogy vegre a, megoldottak a whitespace-mizeriat, b, ertelmet is adtak neki.

A K&R indentation style amit a legtöbb C/C++/Javascript kódban látsz. Valami ilyesmi

if (a==12) {
  fn();
}

Nyitó kapcsos az if/while utasítással egy sorban, záró a blokk mögött külön sorban. Nem igazán átlátható (a kapcsosok nincsenek egymás felett) és semmiféle logika dincs mögötte, mert ha Pl. a helyspórolás a cél, akkor miért van az utolsó kapcsos külön sorban? Valaki egyszer kitalálta hogy így legyen, mert hogy csak. Na most, a mai rendszerekben ez kevésbé probléma, mert van automatikus formázás, de a Go esetén ez be van betonozva a szintaxisba.

Rust "cargo fmt" után szintén zenész, ezt a hagyományt követi:

    if a == 12 {
        fn1();
    }

Itt csak annyi a különbség, hogy nem szokás zárójelezni az if utáni részt, kivéve természetesen a belsejét, ha precedencia indokolja.
Továbbá érdekesség, hogy if/else ágban vissza is térhetsz értékkel. Szintén autoformázás utáni állapot:

    let b = if a == 12 { fn1() } else { -1 };

Ha meg hosszabb, akkor több sorra töri az autoformázás:

    let b = if a == 12 {
        function_teszt()
    } else {
        function_masikteszt()
    };

Nem csalódtam a Rust-ban, Go-ban, nem véletlen, hogy nem szeretem egyiket se. Ez a jelenség engem is mindig zavart tudat alatt, de nem fogalmaztam meg tudatosan, és nem tudtam, hogy szökkenő indentálás a neve. Ez a let = komplett if struktúra is elég átláthatatlan agyrémnek tűnik.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Vannak hideg-meleg dolgok. Nekem is vegyes néhány dologról a megítélésem.
Egy biztos, azt akarták elérni, amit a C az alábbival:

int b = a == 12 ? fn1() : -1;

Azonban erre külön ? és : kifejezést nem akarták bevezetni, a tömör íráshoz maradt az if ... { ... } else { ... }.

let b = if a == 12 { fn1() } else { -1 };

De van még furcsaság, ahol visszatérhet értékkel:

let result = match a {
    1 => 10,
    2 => 30,
    3..=5 => 50,
    _ => -1,
};
let result = loop {
    ...
    if akármi > 10 {
        break akármi * 2; // break és visszatérési érték!
    }
};

mert ez a legolvashatobb sok fuggoleges hely elpocsekolasa nelkul.

btw java standard is, a teljes java ecosystem ezt hasznalja.

A zaro } azert van kulon sorban, mert egy kod blokkot zar le, emiatt egy indent-el kijjebb kerul. Amit irsz, azt egyebkent igy szokas:

if (a==12) fn();

mert ilyen rovidet nem teszunk kulon blokkba. Aztan nehol style guide-ban kieroszakoljak, de en a nyulfarknyi blokkokert harapok. :)

Az olvasható megoldás az az lenne, ha a nyitó kapcsos is külön sorba kerül - ez amúgy messzirõl nézve kb. úgy néz ki mint egy python program :-)

A helytakarékos pedig az, ha a záró kapcsos is az utolsó utasítás mögé kerül. Ez az öszvér megoldás sem nem takarékos, sem nem átlátható. Csak megszokta a nép, mint a windowst vagy az officet.

Most elképzeltem, hogy mondjuk 3-4 egymásba ágyazott blokkból néhányat bezárunk épp, és az utolsó utasítás mögé odabiggyesztünk mondjuk 2-3 }-t, aztán valaki találja ki, hogy melyik oszlopban kell folytatni, illetve ha valaki mondjuk a 2. és a 3. záró között kellene folytassa még pár utasítással, annak nagyon kell majd figyelnie, ne rontsa el. Ha egyáltalán észreveszi, hogy most ott nem egy, hanem több blokknak is vége volt.

Inkább bármi mást.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

>  semmiféle logika dincs mögötte...

De van, mégpedig az, hogy ha sort kell beszúrni, az biztosan a megfelelő helyre kerül. Nem véletlen, hogy ha már egynél több ember dolgozik egy programon, ez a stílus lesz a kézenfekvő választás.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

( Raynes v | 2022. 04. 17., v – 17:45 )

Szerkesztve: 2022. 04. 17., v – 17:52

Elegánsabb a tab, de lustaságból sokszor 4 space-t meg ennek többszöröseit használom. Pythonban mindig is utáltam, hogy a behúzás jelenti a struktúrát, és nem a blokkjelölők. 1-2 space nekem semmiképp nem elég, nem látszik tőle rendesen a struktúra a sokadik szintnél, 2 space fölött ízlés kérdése, hogy mennyi space, vagy tab van-e helyette.

Azért írom, hogy elegánsabb a tab, mert mégis csak ez a legrugalmasabb, mindenki az IDE-jében (nálam neovim) be tudja állítani, hogy ez mekkora behúzást takarjon és hogy le legyen-e cserélve space-ekre, ha annak a megoldásnak híve. Plusz a \t avagy 0x09 ASCII karakter pont erre lett kitalálva, akkor használjuk, amire való, azért van, és még a forráskód mérete is csökken. Mint írtam, néha sajnos előkerül, hogy nem jól beállított editorban, környezetben kell kódot szerkesztenem, ott lustaságból és reflexből nyomatom a 4 space-t meg annak többszöröseit, a többit már a szerkesztő ennek megfelelően húzza be. Gyányolás, de a lustaság nagy úr.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( joco01 v | 2022. 04. 17., v – 18:22 )

A kinézettől van fontosabb is. Van az úgy, hogy keresek egy hosszú stringet egy nagy kódbázisban. Pl. egy elérési út, mert tudni akarom, hogy hol írunk/olvasunk egy adott fájlt. Vagy egy hibaüzenet, ami a logban figyel stack trace nélkül, és tudni kéne, honnan jött. Na ilyenkor lehet agybajt kapni, ha a stringet a megfelelő sorhossz és indentálás miatt széttördelték. Büntetendő kategória.

Ez ellen tudsz védekezni, az IDE/editor/terminál ablakát, betűtípusát úgy állítod be, hogy jó sok karakter férjen ki egy sorba. Ez nem jelent problémát, hiszen a mai átlag 1080p-s, meg afeletti kijelzőkre jó sok minden kifér, én pl. gyatra kijlezőkön felvett szokásból lóméretű (és hinteléssel agyonvastagított) fontokat használok a terminálban, de még nálam is kifér ~150 karakter egy sorba, abba azért elég sokszorosan hosszan beindentált hosszú string is belefér. Vagyis eleférne, ha a szavazásban hivatkozott Python style guide nem ajánlana max. 79 karaktert soronként, ami ma már szerintem elavult, a konzervatív kódolási stílusú Linux kernelnél is lazítottak ezen már azóta. Ma már nem 80 karakterszélességű fizikai terminálokon meg home mikrókon kódolnak az emberek. Ennek ellenére nekem a kódjaimban ritkán megyek 80 karakter fölé, jellemően az alatt maradok, és nem esztétikai korlátból, hanem a hosszú sor a kód érthetőségét rontja egy szinten túl (a „felesleges” sortörés önmagában nem zavarna). Ugyanez igaz a túl sokszorosan behúzott struktúrákra.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Huncraft v | 2022. 04. 17., v – 18:42 )

Ha csak Python lenne, akkor majdnem mindegy, de mivel az IDE több nyelvet is kell támogasson, így egységesebb a szóköz (ha próbáltál már tabolt scriptet bash-be másolni, akkor pontosan tudod miről beszélek :D )

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( tygryss | 2022. 04. 17., v – 20:48 )

Igazából ez volt az egyik fő oka, hogy Julia-ra váltottam :)

Nem igazán erre használom, de a marketing szöveg szerint általános elhasználásra is lehet jó, lehet vele web vagy native UI-t csinaéni, adatbazisokhoz is hozzáférsz, https://juliadatabases.org/ , valamint elvileg le is fordithatod, meg van valami webes dolog is. https://github.com/JuliaWeb/HTTP.jl. Valamint ha valami nagyon nincs valami python parancs ami kell, azt hívhatod PyCall-al, azt hiszem C-t native-ban támogatja, szóval van menekülő út is. Még olyat is láttam, hogy RPi4-et valaki robot irányításra használta, úgy, hogy a code Julia-ban futott a cuccon. https://juliaberry.github.io/ 

Nem mellesleg, ha valami adatelemzés is kell, akkor meg még jobb.  A sebességre sem nagyon lehet panasz, bár van pár dolog ami nem szokványos itt is. Pl a tömbök indexelése 1-től indul. Ennek az oka, hogy matekban 1-től indexelünk. Abban igazad van, hogy a tudományos számításoknál ez nagyon nagy segítség és matekban járatlanabb programozókat ez zavarhatja, de szerintem pythonban azért bőven van zavaróbb dolog is. 

( gelei v | 2022. 04. 17., v – 22:53 )

(x) Nem tudom

Amilyet az IDE használ. Nem is emlékszem, mikor kellett utoljára kézzel identálni valamit. Ha új blokk kezdődik, azt a szerkesztő magától beljebb kezdi. Ha létező kódot akarok beljebb/kijjebb húzni, arra van hotkey, megint nem egyesével kell a sorok elejére kitenni a whitespace-t.

Persze. Ott sem kézzel szoktam adagolni a szóközöket/tabokat. 

Vagy nem értem a kérdést. Ha te kódolsz, akkor kézzel teszed ki a megfelelő whitespace-eket? Ha nulláról kell kódot írni, akkor az editor default whitespace lesz benne, ha máséba kell belenyúlni, akkor meg azt állítom be az editorban, ami a kódban van.

( uid_6201 v | 2022. 04. 18., h – 10:56 )

Python esetén van olyan.parancs, mint Rust esetén a

  • cargo fmt
  • vagy rustfmt *.rs

Azaz ami az identálást, kódkinézetet egységes kinézetre kalapálja?

Ebben a pythonban ha elkezdi valaki/valami kalapalni az indentalast, akkor megvaltozik a program is. Gondolj bele, meg egy `unexpand`-ot sem ereszthetsz ra a kododra, anelkul hogy garantalt lenne hogy ugyazt csinalja mint eddig (oke, persze, ha varsz egy kicsit es nem csinalsz semmit, akkor is lehet hogy megvaltozik a program futtatasanak az eredmenye, ld. osztas atdefinialasa, stb). Mondjuk ettol fuggetlenul lehet ilyen tool, merthat ugye python ;) 

( gee v | 2022. 04. 18., h – 13:14 )

Szerintem tökmindegy. Másnál úgyis úgy jelenik meg, ahogy az ő IDE beállításai szerint jó, vagyis ahogy neki tetszik.

Abból lehet gond, ha többen dolgoznak ugyanazon a kódon és van, aki tab-ot használ, más meg space-t. Ilyenkor vagy meg kell előre állapodni benne, hogy melyik lesz, vagy check-in-kor automatikusan konvertálni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( zdesigner | 2022. 04. 19., k – 11:23 )

1 tab = 4 space, mert úgy van beállítva az IDE-ben.