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 -wTabulá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.