Но вы ведь всё же задумаетесь перед написанием комментария? Вот именно об этом и весь сыр-бор — для зрелого программиста написание комментария это повод немного задуматься.
Заметьте, я нигде не говорил, что комментарий это достаточный признак «плохого кода» — это уже ваши додумки. Так что, попробуйте следовать своему совету и расширять свой кругозор и не считать всех, кто младше ваш априори менее опытными и рассудительными.
Именно поэтому я и советовал почитать книгу полностью, т.к. короткие цитаты вырванные из контекста могут нанести вред, будучи принятыми буквально и фанатично.
Дался вам этот SRP… нет, не является. Комментарии в коде могут означать что угодно, от желания к излишней подробности до неудачного дизайна. Самый частый случай комментариев на моем опыте — это неудачное именование; следующий по частоте — недостаточная выразительность языка в части контрактов (попробуйте в .net без комментариев указать, какие исключения и когда бросает метод), потом — желание писать тривиальные вещи «лишь бы были комментарии», и только потом — группировка кода. И да, здесь осознанно перемешаны нужные и ненужные комментарии.
(я, естественно, не рассматриваю документирующие комментарии)
А в моей практике именно такие же примеры, как и в статье — куча кода в одном методе разбито комментариями. Так что я говорю с позиции своего опыта и моя позиция, как мне кажется, совпадает с тем, о чём писал автор в статье и о чём писал Фаулер в своей книге. Вас удивляет как это так бывает, что всё не как у вас?
Вы знаете, что является необходимым условием для рефакторинга?
Причём тут это? Вы не согласны с тем, что написание коментариев в блоках кода должно вас насторожить и вы должны подумать «а не нужно ли здесь переделать код»? Ну ок, чё. Ваше право. Уровень программистов и стиль программирования у всех разный.
Понятно. В этом, простите за прямоту, ваша беда. Особенно, конечно, это смешно, учитывая следующую цитату из столь любимого вами Фаулера (причем прямо из той книги, которую вы приводите): «McConnell, Code Complete [...] An excellent guide to programming style and software construction. Written before Java, but almost all of its advice applies.» Почитайте, это полезно. Внезапно узнаете, что то, что я цитирую из Фаулера — это всего лишь сокращенная (и упрощенная) версия того, что пишет МакКоннелл.
Скажите, а где я сказал, что вы цитируете Фаулера?
Собственно, в этом и состоит моя к вам претензия: не надо подменять понятия (комментарии vs SOLID) и книги.
Ещё раз — комментарии в большинстве случаев (а особенно в тех, о чём пишется в данной статье) являются следствием нарушения SOLID принципов, а именно SRP принципа. Приведённая мною книга показывает почему так делать плохо и как это нужно исправлять. Что вас тут ещё непонятного, что вы аж попутали какие-то там понятия?
Это не то, о чем статья, это то, что вы в ней вычитали. Это совсем не одно и то же.
Т.е. вы теперь пытаетесь доказать мне, что моё личное мнение неверно просто потому, что оно расходиться с тем, как вы поняли эту статью? Т.е. то, что я могу неправильно понять статью это допустимо, но вы не допускаете мысли о том, что вы сами неправильно всё поняли?
Ага. Но комментарии и SOLID тут не при чем (более того, Фаулер вообще ни разу про SOLID в этой книге не упоминает). Собственно, здесь вы и подменяете понятия.
Как я уже упомянул, код напичканый комментариями в подавляющем большинстве случаев представляет собой явный пример нарушения SRP принципа и подлежит рефакторингу (к примеру, Extract Method) после которого необходимость в коментариях отпадёт сама собой.
Именно это вы и цитируете — комментарии это признаки плохого кода. Само их наличие лучше чем ничего, но это всё ещё попытка украсить плохой код (метафора про дезодорант). И появление комментариев в уже работающем коде (о чём вы упоминаете) тоже должно вас, как хорошего разработчика, насторожить — возможно, это вполне оправданно, но как правило это явный признак лени сделать сразу как надо (разнести по методам или применить другие методы рефакторинга).
Не надо оправдывать «костыли» в программе тем, что без них она бы вообще не работала и вы бы не сдали проект — все и так это понимают, но это всё равно не делает такое решение правильным.
К сожалению, я не читал предлагаемой вами книги, но я склонен допускать, что она тоже способна показать то, о чём пытался сказать автор в более понятном и развёрнутом виде. Вот только ваши «наезды» на мою точку зрения просто потому, что я указал на другую книгу мне абсолютно непонятны. У вас холивар против Фаулера чтоль?
Во-первых, вся статья о том, что нужно более чётко следовать доктринам SOLID, т.к. в большинстве случаев (и в статье как раз об этом примеры) код с коментариями противоречит минимум SRP принципу.
Книга как раз говорит не только о том как нужно рефакторить старый код, но и зачем это делать. Но вы, видимо, не читали эту книгу и свято уверены, что поняли о чём она просто по названию. Вы неправы. И Фаулер достаточно хорошо показывает то, о чём автор пытался объяснить в статье.
Если вам претит Фаулер — ваше право. Вот только не надо пытаться свои предпочтения выдать за факты.
На ваш вопрос я могу ответить (тем, что будет сохранена и донесена информация о том, что делает код до этапа рефакторинга), но я этого не делал, т.к. считаю что вы с вашим вопросом уже отошли от темы — статья о том, как нужно писать код, а не о том, что вам досталось «в наследство» для поддержки. Мы не говорим в стиле «не можете писать SOLID, пишите хотя бы коментарии» — я с этим утверждением согласен, но мы тут говорим о том, как надо «по уму».
Из вашего высказывания очевидно, что вы не читали эту книгу.
В статье автор немного сумбурно (на мой взгляд) пытается донести весьма важную вещь о написании SOLID кода. Наиболее удачно и понятно об этом (опять же, на мой взгляд), написал Фаулер в вышеприведённой книжке. О чём я и написал в своём комментарии для тех, кто любознателен и хочет более подробно разобраться в вопросе.
Не понимаю как это не относится к обсуждаемому вопросу. Может поясните?
Если для небольших объёмов — тогда да. Но тут уже легче будет использовать сервисы мета-облаков, которые позволяют синхронизировать несколько бесплатных облаков — вероятность того, что все разом перестанут работать почти не существует.
Даже снимки с телефонов сейчас занимают очень много места. Не говоря про зеркалки, где крайне желательно хранить raw файлы в архиве. Плюс музыка (опять же, зачастую в loseless форматах). Фильмы. Я не сильно представляю как терабайт личных данных будут распределены и продублированы по телефонам с 14 гб (в среднем) памяти на борту. И это если представить, что интернет у нас быстрый-быстрый.
На счёт «помрёт диск» — я поэтому и сказал про NAS, т.к. там уже сразу идёт поддержка Raid-ов. А HDD сейчас очень дешёвые. Ставьте два диска по 2-4 ТБ в Raid 1 и у вас получается решение ваших задач без лишних хлопот.
Всем, кто не согласен с автором (или просто не понял что автор хотел донести) рекомендую почитать книгу Фаулера «Improving the Design of Existing Code»:
У меня такая. Автор не сказал про главную «особенность» — телефон (Nexus 4) иногда очень сильно нагревается при зарядке об эту штуковину. Мне кажется из-за этого девайса у моего нексуса когда-нибудь выгорит его несъёмная батарея.
А пыль — это фигня. Ставить нужно просто так, чтобы телефон уже касался снизу стола. К тому же можно антистатиком обработать. Да и вообще, пыль почаще в доме протирать )
Из подобных вещей я чаще всего использую || для обработки undefined и null / false значений:
function GetRow (index)
{
return $("selector").eq (index || 0);
}
Аналогично для строк:
$("selector").val (n || "")
Особенно это актуально когда конструируем data для ajax запроса, т.к. там если в поле передадим «undefined», то на сервер это в null не переведёт и будет ругаться (по крайней мере для MVC2 это так).
Сам использую другую программу (JustReader — все остальные у меня часто переставали грузить картинки когда их количество сильно возрастает). Но суть та же, что и у вас (я ещё использую «отметить как избранное», т.к. на них не распространяется лимит давности для оффлайн хранения).
Я уже начал смотреть в сторону Currents, но без нативной возможности просмотра из под винды (браузер или приложение) как-то тоже мимо.
Пока в качестве альтернативы присмотрел только feedly
Mass Effect ниже Сапёра. Репрезентативность выборки вводит заядлого геймера как я в шок, но и даёт основания прогнозировать с большой точностью результаты подобных «опросов» от автора на тему «лучшие рестораны мира».
Заметьте, я нигде не говорил, что комментарий это достаточный признак «плохого кода» — это уже ваши додумки. Так что, попробуйте следовать своему совету и расширять свой кругозор и не считать всех, кто младше ваш априори менее опытными и рассудительными.
Пожалуй, вот этим «перлом» и закончим.
Это же можно отнести к статье.
А по профилю вам 32 года… странно.
А в моей практике именно такие же примеры, как и в статье — куча кода в одном методе разбито комментариями. Так что я говорю с позиции своего опыта и моя позиция, как мне кажется, совпадает с тем, о чём писал автор в статье и о чём писал Фаулер в своей книге. Вас удивляет как это так бывает, что всё не как у вас?
Причём тут это? Вы не согласны с тем, что написание коментариев в блоках кода должно вас насторожить и вы должны подумать «а не нужно ли здесь переделать код»? Ну ок, чё. Ваше право. Уровень программистов и стиль программирования у всех разный.
Скажите, а где я сказал, что вы цитируете Фаулера?
Ещё раз — комментарии в большинстве случаев (а особенно в тех, о чём пишется в данной статье) являются следствием нарушения SOLID принципов, а именно SRP принципа. Приведённая мною книга показывает почему так делать плохо и как это нужно исправлять. Что вас тут ещё непонятного, что вы аж попутали какие-то там понятия?
Т.е. вы теперь пытаетесь доказать мне, что моё личное мнение неверно просто потому, что оно расходиться с тем, как вы поняли эту статью? Т.е. то, что я могу неправильно понять статью это допустимо, но вы не допускаете мысли о том, что вы сами неправильно всё поняли?
Как я уже упомянул, код напичканый комментариями в подавляющем большинстве случаев представляет собой явный пример нарушения SRP принципа и подлежит рефакторингу (к примеру, Extract Method) после которого необходимость в коментариях отпадёт сама собой.
Именно это вы и цитируете — комментарии это признаки плохого кода. Само их наличие лучше чем ничего, но это всё ещё попытка украсить плохой код (метафора про дезодорант). И появление комментариев в уже работающем коде (о чём вы упоминаете) тоже должно вас, как хорошего разработчика, насторожить — возможно, это вполне оправданно, но как правило это явный признак лени сделать сразу как надо (разнести по методам или применить другие методы рефакторинга).
Не надо оправдывать «костыли» в программе тем, что без них она бы вообще не работала и вы бы не сдали проект — все и так это понимают, но это всё равно не делает такое решение правильным.
К сожалению, я не читал предлагаемой вами книги, но я склонен допускать, что она тоже способна показать то, о чём пытался сказать автор в более понятном и развёрнутом виде. Вот только ваши «наезды» на мою точку зрения просто потому, что я указал на другую книгу мне абсолютно непонятны. У вас холивар против Фаулера чтоль?
Книга как раз говорит не только о том как нужно рефакторить старый код, но и зачем это делать. Но вы, видимо, не читали эту книгу и свято уверены, что поняли о чём она просто по названию. Вы неправы. И Фаулер достаточно хорошо показывает то, о чём автор пытался объяснить в статье.
Если вам претит Фаулер — ваше право. Вот только не надо пытаться свои предпочтения выдать за факты.
На ваш вопрос я могу ответить (тем, что будет сохранена и донесена информация о том, что делает код до этапа рефакторинга), но я этого не делал, т.к. считаю что вы с вашим вопросом уже отошли от темы — статья о том, как нужно писать код, а не о том, что вам досталось «в наследство» для поддержки. Мы не говорим в стиле «не можете писать SOLID, пишите хотя бы коментарии» — я с этим утверждением согласен, но мы тут говорим о том, как надо «по уму».
В статье автор немного сумбурно (на мой взгляд) пытается донести весьма важную вещь о написании SOLID кода. Наиболее удачно и понятно об этом (опять же, на мой взгляд), написал Фаулер в вышеприведённой книжке. О чём я и написал в своём комментарии для тех, кто любознателен и хочет более подробно разобраться в вопросе.
Не понимаю как это не относится к обсуждаемому вопросу. Может поясните?
На счёт «помрёт диск» — я поэтому и сказал про NAS, т.к. там уже сразу идёт поддержка Raid-ов. А HDD сейчас очень дешёвые. Ставьте два диска по 2-4 ТБ в Raid 1 и у вас получается решение ваших задач без лишних хлопот.
А пыль — это фигня. Ставить нужно просто так, чтобы телефон уже касался снизу стола. К тому же можно антистатиком обработать. Да и вообще, пыль почаще в доме протирать )
Из подобных вещей я чаще всего использую || для обработки undefined и null / false значений:
Аналогично для строк:
Особенно это актуально когда конструируем data для ajax запроса, т.к. там если в поле передадим «undefined», то на сервер это в null не переведёт и будет ругаться (по крайней мере для MVC2 это так).
Я уже начал смотреть в сторону Currents, но без нативной возможности просмотра из под винды (браузер или приложение) как-то тоже мимо.
Пока в качестве альтернативы присмотрел только feedly