Всеки разработчик, през целия си живот, трябва да се справя с дълбоко обосновано съмнение; преди да избере най-добрия език или предпочитания редактор, (sh|h)e трябва да се присъедини към страна... тъмна или ярка.
Това сложно решение раздели цели екипи, измъчва се от „brogrammers“, счупи няколко любими програмисти, създаде грешни конфигурации в десетки IDE…
Това е неудачният избор между ИНТЕРВАЛи ТАБза отстъп и подравняване на изходния код; вечен дебат, който за някого е конкретна война между фракции!
Малко история
Думата tabпроизлиза от думата tabulate, което означава „подреждане на данни в табличен вид, или таблица, форма.”
Когато човек искаше да напише таблица (с числа или текст) на пишеща машина, имаше много време - отнемащо и повтарящо сеизползване на клавишите space и backspace.
За да опростите това, хоризонтална лента беше поставена в механизма, наречен табулатор. Натискането на клавиша табулатор ще придвижи каретката до следващата спирка на табулатора. Оригиналните ограничители на табулатора бяха регулируеми скоби, които можеха да се преместват от място на място върху стойката на табулатора. Фредрик Хилард подава патентна заявка за такъв механизъм през 1900г. — Уикипедия
В днешно време клавишът tab може често да се използва за преместване на селекцията от елементи на потребителския интерфейс, като се избягва използването на мишката или въпреки това за автоматично попълване на предложена дума.
Така че защо използваме раздели, докато кодираме!?
Е… не се случи съвсем неочаквано. Както всичко, има PRO за такъв избор.
- Символите TABs заемат по-малко байтове
- Ширината на TAB може лесно да се конфигурира в почти всички (сериозни) редактори, като се избягва физическото актуализиране на всеки отделен файл
- TAB-ите са по-лесни за съпоставяне (тъй като съвпадащите интервали може да изберат нежелани)
- TABs са по-лесни за манипулиране, защото няма „превод“, нито интерпретация
От друга страна, SPACE винаги е бил там и също в този случай имаме PRO за използването му...
- С SPACE файлът е последователен във всички редактори
- Няма бъркане с персонализирани вдлъбнатини поради факта, че SPACE е единична единица, която ще бъде по-прецизна по дефиниция
ЗАБАВНИ ФАКТИ ОТНОСНО БЕЗКРАЙНИТЕ АРГУМЕНТИ ЗА ФИЛИБУСТЪР ЗА ПОСЛЕДНИЯ ЧОВЕК ОТНОСНО ФОРМАТИРАНЕТО НА КОДА
Графиките по-горе описват възникващ феномен, при който изглежда, че тези, които използват SPACEs, са склонни да имат по-висока заплата.
Искате ли да навлезете дълбоко в тази мистерия?
Ето я и цялата статия: https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
В заключение
Анархията при форматиране на код е добре, ако сте сами в проект; това става висок приоритет, ако работите в екип и не забравяйте, че е пропорционално на броя на хората, с които работите.
Наличието на добре оформен код с разпознаваеми визуални модели може да повиши способността ви да преглеждате бързо през него.
Форматирайте, не водете война. Когато сте в екип, опитайте се внимателно да проследите и да се споразумеете относно най-добрите общи практики за форматиране. Важно е да споделяте конфигурации на IDE или да използвате lintersпо време на разработката.
Нека това бъде често срещанои информирано решение, а не тъпа принуда.
Ако самоуправлението не работи, нека помислим за създаването на официална роля, която да отговаря за извършването на преразглеждане на код и почистване.
НО... бъдете внимателни; не искате този колега да носи вината за грешки, направени от други. Ако наистина имате нужда от такава фигура в екипа си, програмирането по двойки и сесиите за мозъчна атака може да са по-добри от „нощните прегледи на кода“.
Кодът е поезия, всеки софтуер има своя собствена метрика и поток;
добре е да си креативен, елегантен и пестелив, но най-важното е да си последователен.
