Баги копипасты, нечаянное использование глобальных переменных с тем же именем... C++ вообще троллит неоднозначными записями вроде x y(z); Зато какое облегчение, когда дело бага раскрыто.
Думать о том, где таб, а где пробел, когда ситуация требует отступа, состоящего из N уровней вложенности и M знакомест (о чём было в оригинальном комментарии). Но если исключить такие места из программы и не пытаться выравнивать столбцы, то табы станут простыми и понятными.
Не надо так строго с собой. Нужно продолжать жить.
Программисту надо думать над решением задачи. Человек не может всё удержать в голове. Если программист отвлекается на пробелы, он рискует упустить что-то важное. Поэтому у нас подсветка синтаксиса, подсказки сигнатур функций, кнопка "автоформат" и т.д. Всё для того, чтобы программист не отвлекался на маловажную хрень, которая не связана с решением задачи.
"return" обычно подсвечивается как ключевое слово Присваивание переменной-аккумулятору результата (своего рода return, только не return) - нет. И от увеличения вложенности только глаза разбегаются. Только сворачивание кусков кода в IDE/редакторе может оправдать такой подход. Вот внезапный return где-то в глубине блоков - это да, можно не заметить. Но все эти неохватываемые взглядом методы наверно уже проще разбить на несколько штук.
Если программиста сложно научить использовать табы... Если программиста сложно научить писать машинный код... Если программиста сложно научить вставлять перемычки...
Проблема в удобстве и автоматизации. Работа с пробелами успешно автоматизирована. Жмём таб - добавляется N пробелов и т.д. С табами автоматика глючит и скорее всего заменит отбивку до нужной ширины пробелами на табы, из-за чего всё будет разъезжаться с другим размером табов. Пробелы автоматизированы, с пробелами не надо думать над СУКА МАТЬ ИХ НЕВИДИМЫМИ СИМВОЛАМИ, и можно писать код. Как будто программисту не о чем подумать, кроме о том, как правильно поставить в коде таб. Это просто отвлекает от сути. Так почему бы не убрать эту хрень и пересесть всем на пробелы?
Не надо убивать. Выглядит логично. "Если вот такая маленькая фигня, return 0" "Если ещё другая фигнюшка, return 1" "Ну а когда вот такой поворот, return 2" "Теперь все частные случаи перебрали и перейдём к самой сути"
Записывать результат в отдельную переменную, которая меняется внутри функции и возвращается в конце - запутывать читателя. Создавать вложенность if(x) { return y; } else { весь остальной код } - тоже не очень.
Табы поедут, если программист не понимает, когда нужны табы, а когда пробелы, например табы int x = 1, табы пробелы y = 2; // y строго под x для любого размера таба Поэтому, легче использовать пробелы, чем учить всех программистов правильно использовать табы.
Это указание смысла выражениям. В нормальном коде они должны звучать не как var1, var2 и var3, а иметь название, которое поможет лучше разобраться в сути кода. Например: (x != null && size(x) > 0) и xIsNotEmpty
То есть дать сложному выражению понятное имя, которое упростит жизнь читающему код - это говнокод? Да вы, батенька, небось и функции вручную инлайните, чтоб говнокода не было? Вот не надо заветы микроконтроллерщиков тянуть в остальной мир. Нормальный компилятор под популярную платформу сейчас творит чудеса и выкомпилит он эти лишние переменные из кода ко всем чертям. Особенно, если они использовались только в одном месте.
О себе: Array.prototype.map, Array.prototype.reduce и конечно же Array.prototype.toString С нами с: 2013-12-14 Последний раз заходил: 2018-03-31 Дней подряд: 1
Спасибо! Всем программистам удачи!
Но если исключить такие места из программы и не пытаться выравнивать столбцы, то табы станут простыми и понятными.
Программисту надо думать над решением задачи. Человек не может всё удержать в голове. Если программист отвлекается на пробелы, он рискует упустить что-то важное.
Поэтому у нас подсветка синтаксиса, подсказки сигнатур функций, кнопка "автоформат" и т.д. Всё для того, чтобы программист не отвлекался на маловажную хрень, которая не связана с решением задачи.
Ну тогда удачи и интересных проектов!
Присваивание переменной-аккумулятору результата (своего рода return, только не return) - нет.
И от увеличения вложенности только глаза разбегаются. Только сворачивание кусков кода в IDE/редакторе может оправдать такой подход.
Вот внезапный return где-то в глубине блоков - это да, можно не заметить.
Но все эти неохватываемые взглядом методы наверно уже проще разбить на несколько штук.
Проблема в удобстве и автоматизации. Работа с пробелами успешно автоматизирована. Жмём таб - добавляется N пробелов и т.д. С табами автоматика глючит и скорее всего заменит отбивку до нужной ширины пробелами на табы, из-за чего всё будет разъезжаться с другим размером табов.
Пробелы автоматизированы, с пробелами не надо думать над СУКА МАТЬ ИХ НЕВИДИМЫМИ СИМВОЛАМИ, и можно писать код.
Как будто программисту не о чем подумать, кроме о том, как правильно поставить в коде таб. Это просто отвлекает от сути. Так почему бы не убрать эту хрень и пересесть всем на пробелы?
"Если вот такая маленькая фигня, return 0"
"Если ещё другая фигнюшка, return 1"
"Ну а когда вот такой поворот, return 2"
"Теперь все частные случаи перебрали и перейдём к самой сути"
Записывать результат в отдельную переменную, которая меняется внутри функции и возвращается в конце - запутывать читателя.
Создавать вложенность if(x) { return y; } else { весь остальной код } - тоже не очень.
табы int x = 1,
табы пробелы y = 2; // y строго под x для любого размера таба
Поэтому, легче использовать пробелы, чем учить всех программистов правильно использовать табы.
Например: (x != null && size(x) > 0) и xIsNotEmpty
Да вы, батенька, небось и функции вручную инлайните, чтоб говнокода не было?
Вот не надо заветы микроконтроллерщиков тянуть в остальной мир.
Нормальный компилятор под популярную платформу сейчас творит чудеса и выкомпилит он эти лишние переменные из кода ко всем чертям. Особенно, если они использовались только в одном месте.