Пошёл на границу Португалии, взял прожектор, брезент, и перевёл.
Потом с матюгами и под ржач пограничников выдолбил гномон так чтобы в проекции было "relógio".
Ну или заранее попросил скульптора сделать нужный (ака из репозитария взял).
Формально всё выполнено.
...
Сука, ТЗ забыл подписать...
забавно что люди под обучением языку понимают не синтаксис и правила языка, а использование бесконечного количества библиотек в реальных задачах.
выучить С++ можно за 15 минут при наличии знаний любого другого языка например java ну и нормального уровня знания английского, без английского совсем бида.
Нет, ты либо забыл сколько там всего есть, либо и не знал. На первый взгляд чуть-чуть, а как углубишься... Может и 21 дня не хватить, чтоб понять весь этот синтаксис и правила языка.
вы путаете язык и библиотеки, с одним синтаксимом будешь писать велосипеды, потому что библиотеки уже лет 20 как есть про всё на свете.
тот же опенгл на совершенно любом языке который поддерживает вызов процедур совершенно одинаково работает, что на яве, что на с#, что на С, на языках которые не поддерживают вызов процедур он тоже работал бы одинаково, но увы и ах, вызова процедур нетути.
Отводишь 30% объёма кода на содержательные комментарии, распределяя их в шапку файла (объяснение, нафига он нужен и вообще глобальные сведения про него), перед каждой функцией (нафига нужна, в чём смысл аргументов и что возвращает в каком случае) и по строчкам кода, объясняя на естественном языке смысл происходящего.
И нет проблем, но это же надо не быть ленивой сволочью и вообще уметь внятно изъясняться на естественном языке. А с этим у многих кодеров проблемы и это одно из отличий кодера от программиста.
Друг мой, не всегда есть время. Бывает, что нужно сделать еб*нутую, извиняюсь, задачу на прошлой неделе. Тут не до комментов.
В целом - ты абсолютно прав, но бывают разные ситуации.
"Лучшая документация к коду - это сам код."(с)
Внятные названия функций, читабельность, использование общепринятых подходов - в это случае код будет понятен посторонним разработчикам. А комментарии нужно сначала написать, а потом поддерживать в актуальном состоянии.
Внятно написанный алгоритм/код не требует комментариев, соответственно места, которые содержат много комментариев, потенциально гавно собачачье, требующее переделки.
Комментарии безусловно надо поддерживать в актуальном состоянии. А "понятен" код сам только автору и только первый месяц. А если ты не писал нетривиального кода, потому как алгоритм нетривиален, то много же открытий чудных готовит просвящения дух тебе... Многотредовое программирование с общей память, race conditions, мутексы и read-mostly locks, ммм...
Комментарии безусловно надо поддерживать в актуальном состоянии.
да, только времени на это обычно нет и через пару лет код загроможден ошметками ничего не значащих комментов. Поэтому лучше писать читабельный код.
А "понятен" код сам только автору и только первый месяц.
ну это неправильно, значит код сомнительного качества.
А если ты не писал нетривиального кода, потому как алгоритм нетривиален, то много же открытий чудных готовит просвящения дух тебе... Многотредовое программирование с общей память, race conditions, мутексы и read-mostly locks, ммм...
это хорошо, что ты столько умных слов знаешь, но ни ты, ни я не первые люди которые с этим столкнулись. Давно уже все придумано и отработано как нужно и как не нужно делать.
race conditions
а это вообще признак низкой квалификации автора кода. Если программист такое пишет значит он не понимает что делает.
У меня не раз бывало так, что нужно как-то дополнить, изменить, доработать свой прошлый код спустя месяца три. И нужно для начала понять что тут происходит. Ну так вот, в основном эмоции у меня заключались тогда в "них*я себе, неужели я и правда это писал? *бать я гений! (в хорошем смысле слова)".
Потом с матюгами и под ржач пограничников выдолбил гномон так чтобы в проекции было "relógio".
Ну или заранее попросил скульптора сделать нужный (ака из репозитария взял).
Формально всё выполнено.
...
Сука, ТЗ забыл подписать...
выучить С++ можно за 15 минут при наличии знаний любого другого языка например java ну и нормального уровня знания английского, без английского совсем бида.
вы путаете язык и библиотеки, с одним синтаксимом будешь писать велосипеды, потому что библиотеки уже лет 20 как есть про всё на свете.
тот же опенгл на совершенно любом языке который поддерживает вызов процедур совершенно одинаково работает, что на яве, что на с#, что на С, на языках которые не поддерживают вызов процедур он тоже работал бы одинаково, но увы и ах, вызова процедур нетути.
И нет проблем, но это же надо не быть ленивой сволочью и вообще уметь внятно изъясняться на естественном языке. А с этим у многих кодеров проблемы и это одно из отличий кодера от программиста.
В целом - ты абсолютно прав, но бывают разные ситуации.
А если серьёзно, то на понимание кода гораздо лучше работает следование паттернам типа MVC и гайдлайнам фреймворков.
Внятные названия функций, читабельность, использование общепринятых подходов - в это случае код будет понятен посторонним разработчикам. А комментарии нужно сначала написать, а потом поддерживать в актуальном состоянии.
Внятно написанный алгоритм/код не требует комментариев, соответственно места, которые содержат много комментариев, потенциально гавно собачачье, требующее переделки.
да, только времени на это обычно нет и через пару лет код загроможден ошметками ничего не значащих комментов. Поэтому лучше писать читабельный код.
А "понятен" код сам только автору и только первый месяц.
ну это неправильно, значит код сомнительного качества.
А если ты не писал нетривиального кода, потому как алгоритм нетривиален, то много же открытий чудных готовит просвящения дух тебе... Многотредовое программирование с общей память, race conditions, мутексы и read-mostly locks, ммм...
это хорошо, что ты столько умных слов знаешь, но ни ты, ни я не первые люди которые с этим столкнулись. Давно уже все придумано и отработано как нужно и как не нужно делать.
race conditions
а это вообще признак низкой квалификации автора кода. Если программист такое пишет значит он не понимает что делает.