Ай-яй-яй, комментарии внутри метода -не кошерно.. И почему сам метод без xml описания? Не по код-стандарту сие баловство..
А за выбор профессии плюс. Не слушай ни кого, разработчики - это круто.=)
А за выбор профессии плюс. Не слушай ни кого, разработчики - это круто.=)
раскрыть ветку (39)
Открою страшную тайну - картинка кода нагло найдена в инете))) Т.к. выкладывать на пикабушный суд реальный код это самоубийство!)
раскрыть ветку (6)
ещё комментарии
Он может там быть.. Но если код требует комментария, то это "плохой" код.. Хорошим стилем считается только описание, что метод делает, а не попытка объяснить, какой сумбур в нем происходит..
раскрыть ветку (24)
Байка про то, что "хороший" код не требует комментариев - это всего лишь байка, распространенная в мозгах типа-крутых-программистов.
Комментировать код можно и нужно (правда комментарии тоже разные бывают - и хорошие, и плохие).
Комментировать код можно и нужно (правда комментарии тоже разные бывают - и хорошие, и плохие).
раскрыть ветку (8)
Писать очевидно и понятно - это только "типа-круто"? Может это еще сокращает время работы других людей с твоим кодом?
раскрыть ветку (7)
Я не говорил, что наличие комментариев автоматически означает, что можно говнокодить.
То, что кажется очевидным кому-то здесь и сейчас - не обязательно будет очевидным кому-то другому. И даже самому автору, скажем, через год. Если, конечно, речь идет о чем-то сложнее hello world или решения квадратного уравнения.
"Хороший код сам за себя говорит" - это иллюзия. И если кто-то этого не понимает - значит он просто пока не имел дел с реальной поддержкой сложного проекта.
То, что кажется очевидным кому-то здесь и сейчас - не обязательно будет очевидным кому-то другому. И даже самому автору, скажем, через год. Если, конечно, речь идет о чем-то сложнее hello world или решения квадратного уравнения.
"Хороший код сам за себя говорит" - это иллюзия. И если кто-то этого не понимает - значит он просто пока не имел дел с реальной поддержкой сложного проекта.
раскрыть ветку (6)
Все правильно. У меня есть папочка, где лежат скрипты, которые я сам писал, но в сути работы которых до сих пор разобраться не могу. Потому что прошло несколько лет и я просто все забыл.
А были бы комментарии..
А были бы комментарии..
раскрыть ветку (2)
Сочувствую. Однако, скрипты и коммерческий код все же имеют большие различия. Мне тоже приходится иметь с ними дело, писать на cmd и powerShell, для тех.поддержки. Эти скрипты я забываю уже на следующий день, ибо жутко не люблю. Там да, комментарии лучше оставлять в достаточном количестве.
раскрыть ветку (1)
Ну скриптами сейчас много что назвают. JS весь например.
Я лично был свидетелем, как в фирме огромный продукт на PHP (несколько тысяч файлов-модулей) называли "скрипт" - видимо просто по инерции, с тех времен, когда он был небольшим :)
Я лично был свидетелем, как в фирме огромный продукт на PHP (несколько тысяч файлов-модулей) называли "скрипт" - видимо просто по инерции, с тех времен, когда он был небольшим :)
Вот это очень хороший вопрос об очевидности и что кажется очевидным тебе самому в данный момент. Есть такой инструмент - code review, одной из плюшек которого и является проверка этой самой очевидности. Если мне на ревью задают вопросы "почему?", а уж тем более "как?" или "зачем?", то это тревожный звоночек и этот кусок кода нужно рефакторить.
Так же, хочу убедится, что меня поняли правильно. Я не сказал, что комментариев в коде не может быть абсолютно. Но их наличие является предупреждением, что что-то начало идти не так. За исключением реализации сложных математических алгоритмов, там без комментариев и описания действительно все тухло. Ну, или при работе со сторонними библиотеками, которые могут вести себя весьма "загадочно" и нет варианта от них отказаться.
И если так посмотреть, то выше перечисленные случаи, а так же не перечисленные, при которых код требует комментария - являются вынужденными исключениями (ставят разработчика в затруднительную ситуацию). Во всех остальных случаях, если тебе требуется прокомментировать сам код, то это: 1. неадекватные названия переменных, 2. недостаточный рефакторинг (это как сложность алгоритма работы так и его обширность), 3. недостаточные знания проекта и платформы, 4. ошибки на на уровне архитектуры.
Если с тремя первыми ты в состоянии справиться сам (поменять имена, упростить алгоритм или разбить слишком большой метод на несколько приватных), то с третьим вариантом действительно проблема. Тут все зависит от того, на сколько глубоко лежит эта ошибка, сколько есть времени и т.п. Четвертый пункт, опять же является исключительной ситуацией и при хорошо поставленной работе компании возникает крайне редко.
Так же, хочу убедится, что меня поняли правильно. Я не сказал, что комментариев в коде не может быть абсолютно. Но их наличие является предупреждением, что что-то начало идти не так. За исключением реализации сложных математических алгоритмов, там без комментариев и описания действительно все тухло. Ну, или при работе со сторонними библиотеками, которые могут вести себя весьма "загадочно" и нет варианта от них отказаться.
И если так посмотреть, то выше перечисленные случаи, а так же не перечисленные, при которых код требует комментария - являются вынужденными исключениями (ставят разработчика в затруднительную ситуацию). Во всех остальных случаях, если тебе требуется прокомментировать сам код, то это: 1. неадекватные названия переменных, 2. недостаточный рефакторинг (это как сложность алгоритма работы так и его обширность), 3. недостаточные знания проекта и платформы, 4. ошибки на на уровне архитектуры.
Если с тремя первыми ты в состоянии справиться сам (поменять имена, упростить алгоритм или разбить слишком большой метод на несколько приватных), то с третьим вариантом действительно проблема. Тут все зависит от того, на сколько глубоко лежит эта ошибка, сколько есть времени и т.п. Четвертый пункт, опять же является исключительной ситуацией и при хорошо поставленной работе компании возникает крайне редко.
раскрыть ветку (2)
Все это написано как бы правильно, но - идеалистично.
На практике комментарии очень полезны и вовсе не обязательно являются признаком, что "что-то пошло не так".
Но комментарий не должен дублировать собой код - он должен описывать его на более высоком уровне абстракции.
На практике комментарии очень полезны и вовсе не обязательно являются признаком, что "что-то пошло не так".
Но комментарий не должен дублировать собой код - он должен описывать его на более высоком уровне абстракции.
раскрыть ветку (1)
Да ладно тебе, здесь нет правильной или не правильной позиции. Этот спор из разряда спора пятилетней давности "что лучше использовать для разработки игр DirectX или OpenGL". Так что не принимай на свой счет мои ярые отстаивания своей позиции. В любом случае, спасибо за мнение, было интересно побеседовать.=) Удачи.
раскрыть ветку (2)
Я не гонюсь за идеалами, и тем более за идеальным кодом. Так становятся "плохими" разработчиками. Не в плане плохо писать, а в плане ценности для компании. Так как Стива Макконнелла я не читал, то видимо не смогу сейчас вести с тобой спор на должном уровне. За совет спасибо, обязательно прочту и возможно мы вернемся у этому разговору.=)
А пока, я останусь при своем мнении, что задачу без "жестких подводных камней" можно сделать хорошо и это стоит того, что бы потратить время (в рамках задачи, конечно, месяц над подобным вопросом никто не даст залипать).
А пока, я останусь при своем мнении, что задачу без "жестких подводных камней" можно сделать хорошо и это стоит того, что бы потратить время (в рамках задачи, конечно, месяц над подобным вопросом никто не даст залипать).
ну во-первых там тоже может быть описание, а во вторых, я, лично, комментирую иногда то, что пока хочу изменить на другой код, но удалять совсем не решаюсь - мало ли что. кажется вы тут самый "тру" программист..
Ты хоть раз видел проект, в котором больше пары тысяч строк кода? А то складывается ощущение, что твой опыт программирования ограничен студенческими лабами.
раскрыть ветку (10)
Дружище, это было лишнее. Я не особо люблю "писькомерством" заниматься, но если тебя действительно волнует этот вопрос, то вот над этими проектами я работаю в данный момент:
http://elvees.ru/home/index.php?id=49
http://elvees.ru/home/index.php?id=35
Думаю, по описанию проекта и с сайта компании, ты сам сможешь приблизительно представить о их сложности. Думаю, этого будет достаточно.
http://elvees.ru/home/index.php?id=49
http://elvees.ru/home/index.php?id=35
Думаю, по описанию проекта и с сайта компании, ты сам сможешь приблизительно представить о их сложности. Думаю, этого будет достаточно.
раскрыть ветку (9)
Компьютерное зрение в данный момент представлено готовыми технологиями от Intel, IBM и ещё несколько других. Так как я сам сейчас занимаюсь компьютерным зрением, то скажу, что проекты не особо сложные, большое число строк кода может возникнуть в серверной части, но там тоже есть готовые и дешевые решения.
раскрыть ветку (8)
При старте компании, начальник отдела разработки по каким-то причинам был категорически против сторонних библиотек. Так что даже для получения rtsp потока написан свой плагин, а не заиспользован live555. То же самое касается всего остального, вплоть до алгоритмов распознавания. Готовые решения может и есть, но у нас свои. Так же, эти два проекта не являются единственными, есть несколько клиентов этого самого сервера на wpf. И они не являются маленькими. Посему, у нас все свое и рукописное.
раскрыть ветку (7)
раскрыть ветку (6)
Да вот черт его знает. Можно было бы порассуждать о лицензировании, сертификации, особенно для государственных структур и военных. Но если честно, то желания не много. Спор себя исчерпал. Так что удачи и no pasaran.
раскрыть ветку (5)
Мы ставили интеловские технологии для ФСБ. Сертификация и лицензирование, вообще, для других моментов проходится.
раскрыть ветку (4)
ещё комментарии
>комментарии внутри метода -не кошерно
если серьезно, то вполне кошерно если не превращать их в поэму, во многих случаях не стоит про них забывать (Макконнелл, 32 глава)
если серьезно, то вполне кошерно если не превращать их в поэму, во многих случаях не стоит про них забывать (Макконнелл, 32 глава)
раскрыть ветку (5)
Ну на практике очень часто люди обновляют функционал, забывая обновить комментарий. И в итоге в какой-то момент комментарий становится не актуален. Или вообще противоречит коду. И тогда такой комментарий способен порвать мозги кому-то, кто влезает в модуль первый раз. Лично меня такие ситуации жутко тормозят.
Но другое дело что то же самое можно и к "хорошо названным переменным" отнести. Но с ними такое реже происходит. Даже не могу припомнить из ближайшей практики, а вот с комментариями куча косяков была
Но другое дело что то же самое можно и к "хорошо названным переменным" отнести. Но с ними такое реже происходит. Даже не могу припомнить из ближайшей практики, а вот с комментариями куча косяков была
раскрыть ветку (1)
такая проблема с обновлением комментов есть, но у нас могут и по рукам дать на код ревью, после этого при рефакторинге обычно не забывают актуализировать комменты. (НО! внутри метода их обычно немного)
Стива Макконнелла, признаюсь не читал и не могу судить, о каких случаях велась речь.. Но посуди сам, у тебя есть нативный сервер, 4-5 клиентов потребителей с весьма разнообразным gui, пухлая обертка нативной части клеем и обширный фреймворк на все это дело.. И для того, что бы заиспользовать готовый функционал придется лезть в каждый метод компонента, дабы понять, что же он такое делает-то и как с ним обращаться.. Для компании, такой код просто ущербный.. Ибо порядком увеличивает время на разработку команды или нескольких команд..
И да, я говорю про коммерческую разработку на высокоуровневых языках.. Домашних "поделок" это не касается..
И да, я говорю про коммерческую разработку на высокоуровневых языках.. Домашних "поделок" это не касается..
раскрыть ветку (2)
если тебе надо лезть внутрь метода, чтобы понять как его использовать это хреновый метод с неподходящим заголовком и плохой документацией и я с этим согласен.
Комментарии внутри метода обычно предназначены для разработчиков сопровождающих код библиотеки/фреймворка и при рефакторинге могут выручить, особенно если в методе кто-то применил "хитрый ход" (обычно этот хитрый ход становится источником проблем и плохим кодом)
Комментарии внутри метода обычно предназначены для разработчиков сопровождающих код библиотеки/фреймворка и при рефакторинге могут выручить, особенно если в методе кто-то применил "хитрый ход" (обычно этот хитрый ход становится источником проблем и плохим кодом)
раскрыть ветку (1)
Да, по поводу "хренового" метода с плохим описанием, я с тобой полностью согласен. Видимо, я выбрал не совсем подходящий пример.
Давай будем откровенными, наличие "хитрого хода" - это уже не добрый знак. И тут уже нужно разбираться на уровень выше, почему разработчик был вынужден его применить или вообще в принципе оставить комментарий почему он так сделал. Сейчас я говорю не о ситуациях, когда сотрудник не мог сделать лучше, потому что не знал как, а о ситуациях, когда других вариантов не было.
В общем, я пытался сказать не "ни в коем случае не оставляете комментарии, ибо боженька вас накажет", а "если код требует комментария, то в разработке что-то идет не так и это в последствии может вылезти боком". Как-то так.
Давай будем откровенными, наличие "хитрого хода" - это уже не добрый знак. И тут уже нужно разбираться на уровень выше, почему разработчик был вынужден его применить или вообще в принципе оставить комментарий почему он так сделал. Сейчас я говорю не о ситуациях, когда сотрудник не мог сделать лучше, потому что не знал как, а о ситуациях, когда других вариантов не было.
В общем, я пытался сказать не "ни в коем случае не оставляете комментарии, ибо боженька вас накажет", а "если код требует комментария, то в разработке что-то идет не так и это в последствии может вылезти боком". Как-то так.
ещё комментарии
