1994

Стилистические Войны программистов

Когда-то давным давно я склепал и залил в инет несколько юмористических картинок касательно стилистики написания кода на C++, которые мгновенно разлетелись и вызвали тогда много срача жарких дискуссий на эту тему... И вот перерывая свои старые и пыльные архивы я сейчас снова на них случайно наткнулся. Поэтому решил поделиться с вами полной подборкой. :)

Не сочтите за баян, надеюсь, что кого-нибудь вдохновит и он выложит в комментариях свои достойные варианты на эту тему :))

// [0]

Стилистические Войны программистов Программирование, C++, Юмор, Длиннопост

// [1]

Стилистические Войны программистов Программирование, C++, Юмор, Длиннопост

// [2]

Стилистические Войны программистов Программирование, C++, Юмор, Длиннопост

// [3]

Стилистические Войны программистов Программирование, C++, Юмор, Длиннопост

А вот вариант от некоего пользователя под ником Ges( если ты есть на Пикабу, то респект тебе - долго смеялся с твоей картинки :)) )

Стилистические Войны программистов Программирование, C++, Юмор, Длиннопост

P.S. Баянометр ругался на одну отдельно выложенную картинку :)

Лига программистов C/C++

65 постов4.8K подписчиков

Правила сообщества

Соблюдайте правила Pikabu:

https://pikabu.ru/html.php?id=wtf


Помимо этого ЗАПРЕЩЕНО:

- Размещать в сообществе посты стиля "Подскажите как удалить вирус", "Подскажите как установить программу", "Подскажите как починить монитор/телевизор/мышь/тостер/стиральную машину" или "Напишите за меня лабу в универ". Пожалуйста размещайте такие посты вне этого сообщества или в соответствующих для этого сообществах.

Вы смотрите срез комментариев. Показать все
0
Автор поста оценил этот комментарий

Чем меньше код занимает места при одинаковой читабельности - тем лучше. Табуляция и пробелы - тоже место.

раскрыть ветку (30)
24
Автор поста оценил этот комментарий
Чем меньше код занимает места при одинаковой читабельности - тем лучше. Табуляция и пробелы - тоже место.

А поподробней? Чем Лучше?

В компилируемых языках все равно это похерится, для всего остального есть минификаторы.

раскрыть ветку (20)
14
Автор поста оценил этот комментарий

Вообще говоря, все эти кодстайлы в хорошей IDE одним кликом меняются :)

раскрыть ветку (11)
6
Автор поста оценил этот комментарий

Могут возникнуть сложности с системами управления версиями.

раскрыть ветку (10)
2
Автор поста оценил этот комментарий

Какие, к примеру?

раскрыть ветку (9)
7
Автор поста оценил этот комментарий

В диффах будет много различий.

раскрыть ветку (8)
Автор поста оценил этот комментарий
С чего вдруг?
раскрыть ветку (7)
2
Автор поста оценил этот комментарий

таб и пробел - разные символы, значит сменилась не одна строка в файле, а весь файл :)

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

@XaveScor, вам тоже.


Внезапно есть автозамена табов на пробелы и обратно при коммите. Было бы желание.

раскрыть ветку (4)
2
Автор поста оценил этот комментарий
автозамена табов на пробелы и обратно при коммите

никогда не запаривался. все проекты на табах. но имхо - это изврат)

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Изобретение колеса - это тоже изврат) все зависит от точки зрения.
1
Автор поста оценил этот комментарий

Дык а зачем париться, если при работе в IDE нет разницы?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

В том-то и дело, что сейчас только неофитов можно встретить за такими прениями)

1
Автор поста оценил этот комментарий

Потому что после переформатирование меняется текст. Вот эти различия и будут отражены в отчете.

11
Автор поста оценил этот комментарий

Плохой программист пишет код понятный компилятору, хороший - человеку.

Кажется так.

раскрыть ветку (6)
0
Автор поста оценил этот комментарий

Ээ, чего? Компилятору любой правильный код понятен. Если только вы не имеете в виду что код должен проще оптимизироваться (к примеру, довольно часто gcc не умеет в инлайн). Но это будет уже непонятный человеку код, т.е. опять не под ваше высказывание.

раскрыть ветку (3)
5
Автор поста оценил этот комментарий

Код нужно будет читать. Не тебе, так после тебя.


Если ты плохой программист, ты напишешь так, чтобы работало. Потому что компилятору и интерпретатору похер как называются переменные, хоть x1, x2, fff или fuck, как всё выравнено и насколько грамотно организовано. А хороший программист напишет программу так, чтобы её можно было легко читать, модифицировать, расширять и вообще поддерживать. ООП и разные абстракции были придуманы не для скорости работы программы, а для легкости поддержки, контроля сложности кода.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий
Я про первую часть высказывания, вы про вторую.
раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Если код не понятен компилятору, то это ошибочный код, и считать его за программу вообще нельзя.
0
Автор поста оценил этот комментарий

В любом случае в условии стоит "одинаковая читабельность", так что это тут не при чем. Да и если уж идет речь о читабельности, то вопрос экономия места для пробелов и табуляций не в приоритете. Программисты на питоне подтвердят))

0
Автор поста оценил этот комментарий
Неплохо сказано :)
3
Автор поста оценил этот комментарий

Больше инфы на один экран влезает, как минимум

15
DELETED
Автор поста оценил этот комментарий

Меня убедили в том, что название переменных/функций/энумов должны быть как письма бабушке.

Не нужно пытаться писать как можно короче. Нужно писать так, что бы код был читаемым.


Вот две функции. Одна вообще без пояснений что она делает. Другая с подробным описанием. Две функции по задумке делают одно и тоже. Но какая разница в понимании!

Иллюстрация к комментарию
раскрыть ветку (8)
7
Автор поста оценил этот комментарий
didSelect? В прошедшем времени?
раскрыть ветку (6)
1
DELETED
Автор поста оценил этот комментарий

Ну да.

раскрыть ветку (5)
0
Автор поста оценил этот комментарий
Почему не инфинитив?
раскрыть ветку (4)
2
DELETED
Автор поста оценил этот комментарий

Потому что это метод делегата таблицы, который вызывается после того, как ячейка была выбрана.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

тогда почему не что-то вроде OnDid...()? Потому что идёт код:
bla-bla(0;
i++;
didSelectedRow();
как-то не смотрится. Мб надо в контексте посмотреть

раскрыть ветку (1)
2
DELETED
Автор поста оценил этот комментарий

Этот метод напрямую из клиентского кода не вызывается. Его вызывает таблица после того, как в ней была выбрана ячейка (выбрана пользователем). У него есть "брат-близнец" tableView:willSelectRowAtIndexPath:, который вызывается перед тем, как в таблице будет выбрана ячейка.


Т.е. пользователь тыкает пальцем по какой-то ячейке в таблице, потом у делегата этой таблицы вызывается метод tableView:willSelectRowAtIndexPath:. Внутри этого метода можно, например, выбрать другую ячейку вместо той, на которую тыкнул юзер, либо вообще отмерить выбор. После этого ячейка помечается как выбранная (запускается анимация изменения фона и т.п) и после этого вызывается метод tableView:didSelectRowAtIndexPath:, в котором можно дальше обработать событие выбора ячейки.


Оба эти метода опциональны и если делегат их не реализует, то вызываться они не будут.



tableView:didSelect... и tableView:willSelect... читаются как обычные английские предложения, из которых абсолютно очевидно, что делают методы с этими сигнатурами и когда эти методы будут вызываться. В отличии от какого-нибудь onSelect(...), для которого нужно было бы лезть в документацию, чтобы узнать, когда он вызывается, а в особо запущенных случаях и для того, чтобы узнать, что означают его аргументы.


почему не что-то вроде OnDid...()?

потому что это вообще убожество какое-то) Зачем писать подряд On и Did, которые имеют одинаковую семантическую нагрузку в данном контексте и при этом превращают более-менее нормально построенную фразу (DidSelect/OnSelect) в "Маяма твая выбральма, насяльнике"?

1
DELETED
Автор поста оценил этот комментарий

Там нажимается, и сразу в методе отжимается.


Не задавай таких сложных вопросов,  я только учусь =)

1
Автор поста оценил этот комментарий

я использую только 26 названий, a-z.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку