Свой код⁠⁠

Пффф, раньше думал что переписывать чужой код сложно. НО НО потом пришлось работать с cms битриксом с чистой версией, еще не переписаной и скажу вам что лучше бы там кто то уже что то переписал, это какое то Г за 72 к )) Забавно думать что за такие деньги там должно быть все готово, но потом приходится нанимать программиста платить ему еще как за стоимость интернет магазина, очень экономная вещь

Неа - нужно писать код что бы никто никогда его не понял, чем больше goto и меток, тем лучше, чем больше пустышек, которые нихуя не меняют, тем лучше - тебя уволят, а через неделю вернут с повышением зп

Согласен, но это только именование. Другое дело - вспомнить логику приложения, при этом всякие getProduct() или isValid не всегда помогают.

Не всегда работает такой подход, не давно был проект где таблица содержала 80 информативных переменных часть из которых ведут на другие таблицы, так вот направление проекта исследования скважин/нефьте добыча, и названия переменных давление пластовое, давление межпластовое, давление, давление забойное, давление забойное 1 и т. д. вообщем их так то тяжко читать и выстраивать связь, а еще и по переменным искать значение полный атас и к 30 переменной уже понимаешь что называть вещи своими именнами уже нету ни сил ни фантазии, так и живём. ..

И исключения

Слишком простой вариант=). Это никогда не избавит от традиционного вопроса "нахуя". Старые добрые костыли, которые были вставлены давным давно, либо вообще другим разрабом, по только ему известной причине. И не дай боже ты решишь поиграть в умного и прочитав весь остальной код решить что это тут не нужно. С высокой вероятностью огребешь кучу проблем. В итоге в "прочтенном" коде остаются участки с темной магией.
Другой вариант старый проект со старыми уже не использующимися фреймворками. Даже если он красиво написан, не освежив память документацией по нему, трудно будет разобраться.

Мне кажется так и придумали 1с :)

Гы-гы.

ls -hl /mnt/*/*.ru/$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -1 day")/ft-v0[57].$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -1 day").2300*|cut -d/ -f6 > /tmp/VarA

ls -hl /mnt/*/*.ru/$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -${tIme} day")/ft-v0[57].$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -${tIme} day").2300*|cut -d/ -f6 > /tmp/VarB

DiFF=`/usr/bin/diff /tmp/VarA /tmp/VarB|grep .ru`

echo $DiFF

Ах, Clean Code Роберта Мартина. Годная книга, особенно для начинающих

Да прост нужно побольше методов и классов использовать. А то в одном классе в двух методах напишут 500+ строк кода и сиди ковыряй.

Ну то есть комментарии не нужны, все равно читать код, да?

потом придется форки делать изза комментариев.

"

Среди разработчиков системной библиотеки Glibc разгорелась дискуссия, которая привела к противостоянию между Ричардом Столлманом и сообществом и заставила задуматься над применяемыми в проекте методами управления и полномочиях по принятию решений.

Дискуссия началась с утверждения патча, удалившего из описания функции abort() шутку о том, что рассматриваемый правительством США законопроект о цензуре может трактовать информацию о данной функции как пропаганду абортов, поэтому пользователи должны иметь в виду, что функция abort() не является приемлемым способом преждевременного прерывания выполнения программы. Некоторые разработчики посчитали данную шутку излишне политизированной, засоряющей руководство и вызывающей негативные воспоминания у людей, которым пришлось столкнуться с проведением абортов.

В ответ в списке рассылки Glibc появился Ричард Столлман, который указал, что движение GNU не является чисто техническим проектом и попросил вернуть назад шутку, которую он добавил в 1990-х годах и считает вполне уместной и важной с идеологической точки зрения. Он заявил, что документация GNU, как курс по истории, не должна быть безопасным местом, а также в шутку предложил довести дело до абсурда и добавить предупреждение в текст о функциях создания дочерних процессов, так как роды могут быть гораздо более травматичны, чем аборты. Например, как неплохой вариант отмечено предупреждение "создание детей может занять до 9 месяцев и привести к исчерпанию всех ресурсов".

В конечном счёте, натолкнувшись на большое число возражений Столлман заявил, что как руководитель проекта GNU он отвечает за то, что публикуется в руководствах GNU, и он лично определяет критерии, на основании которых принимаются решения. Разработчики попытались возразить, что решения в Glibc в основном принимаются на основании консенсуса, на что Столлман указал, что Glibc не является независимым проектом, а представляет собой часть проекта GNU и официальные мэйнтейнеры утверждаются лично им.

В подавляющем большинстве случаев назначенные мэйнтейнеры сами принимают решения, связанные с их проектами, но иногда возникают исключения, которые заставляют Столлмана вмешиваться в процессы принятия решений. По сложившейся практике в Glibc возникла система принятия решений на основании достижения консенсуса между всеми участниками разработки, но некоторые концептуальные вопросы остаются прерогативой проекта GNU и не могут быть делегированы отдельным подпроектам. Именно таким является вопрос оставления шутки, привлекающей внимание к возможному усилению цензуры.

Торвальд Ригель (Torvald Riegel), один из мэйнтейнеров Glibc из компании Red Hat, входящий в комитеты ISO по стандартизации C++, указал, что пренебрежение коллегиальным мнением сообщества разработчиков является неплохим поводом для форка. Решение об удалении посторонней шутки, которая не имеет отношения к описанию работы функции abort(), было принято коллегиально большинством разработчиков, но Столлман отказался прислушаться к чужому мнению в пользу личных пристрастий.

Несколько мэйнтейнеров Glibc призвали не возвращать шутку пока продолжается обсуждение и не выработано общее соглашение. Тем не менее один из мэйнтейнеров (Alexandre Oliva), несмотря на то, что большинство разработчиков высказались против шутки, уже отменил удаление, сославшись на решение лидера проекта. В качестве компромисса, Столлман разрешил добавить примечание "Предупреждение от Столлмана"."

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

Иллюзия безопасности.

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