«Совершенный код» — отличная книга. Я хотел затронуть лишь те правила, которые использую сам.
Про пункт 6 — замечание очень верное. Комментарии полей, пожалуй, больше для тех, кто будет менять класс «после нас».
Конечно, каждая ситуация отличается, но скорее всего что-то пошло не так.
Я не знаю Вашего кода, как он будет использоваться и так далее, но поддерживать 3000 строчек очень сложно. Обычно есть способы разбивки на функциональные компоненты.
Пожалуй, лишь списки констант иногда выходят очень длинными.
Наверное, всё зависит от того, как привык писать код. Я привык сначала писать комментарии, а потом код. То есть, завожу новый класс, пишу стабы методов, для каждого пришу примерно, что я хочу, чтобы он делал, потом вставляю во внутрь несколько коментов, как он будет это делать, ну а потом и код появляется…
Конечо, для мелких классов или внутренних функций этого нет.
Очень интересные замечания.
Однако, есть несколько контраргументов. Комментарии методов:
1. В комментариях методов стоит намекать на реализацию. В примере с sendPost указано, что будет совершен HTTP запрос. Это значит, например, что эту функцию не стоит вызывать из нити, которая отрисовывает интерфейс.
2. Иногда читаешь только комментарии. Допустим, надо понять что умеет делать класс. Если все методы имеют комментарий, то глазу проще искать синенькие блоки и читать только их. Безусловно, самый плохой случай, когда у части методов комментарий есть, а у части — нет.
3. Иногда надо создать Javadoc. Тогда хоть какой-нибудь комментарий лучше, чем никакой.
Комментарии полей: Обычно у класса есть ссылки на «родительские» объекты, объекты, которые класс контролирует и поля состояния. Мне нравится разделять эти группы и явно указывать, что, например, следующие поля будут постоянно меняться. Потом проще вспомнить, что к чему.
На самом деле это очень спорный момент.
Однажды я работал с очень важным блоком когда, который был написан итальянским разработчиком. Комментов было очень много, но они были на итальянском. Ну и названия переменных и методов были на итальянском.
Моей задачей было переписать этот кусок «чтоб работало также». Scegli una lingua nuova :)
Дополню: иногда приходится писать UI-компоненты. Тогда в заголовке файла с панелькой я обычно рисую схему панельки. Вот так: +--------------------+
| LBL: |
| /FIELD/ |
| BTN/ |
+--------------------+
Спасибо за замечание. Я долго думал, включать этот пункт или нет.
Когда я писал только на Java, всё было просто: тип и видимость переменной подсказывала IDE. Однако, при составлении программ на C-подобных языках, иногда без IDE вообще, понял, что без m_ очень сложно.
Кстати, справедливости ради, стоит отметить, что метод, описанный в посте очень даже остроумен.
Если двое договорятся вести разговор с кандидатом на похожие темы, но с разных сторон, то, и правда, можно узнать много нового.
А я вот люблю работать с людьми, а не человекоподобными роботами.
Вопрос «Приведите пожалуйства пример с последнего места работы, когда Ваша нацеленность на удовлетворение клиента привела к росту дохода компании?» — это вопрос одного робота другому роботу. Цель вопроса — подтверждение их общего роботского интерфейса. Дальнейшая оценка по шкале из К баллов — продолжение роботского протокола.
А я вот люблю работать с людьми. И стараюсь сторониться компаний, где могут задать такой вопрос.
Отличная идея!
У конкретной реализации, безусловно, есть некоторые недостатки. Подход, однако, новый и смелый. Я уверен, что такой трюк будет очень кстати для небольших магазинов, детских порталов и т. п.
Про пункт 6 — замечание очень верное. Комментарии полей, пожалуй, больше для тех, кто будет менять класс «после нас».
Я не знаю Вашего кода, как он будет использоваться и так далее, но поддерживать 3000 строчек очень сложно. Обычно есть способы разбивки на функциональные компоненты.
Пожалуй, лишь списки констант иногда выходят очень длинными.
Наверное, всё зависит от того, как привык писать код. Я привык сначала писать комментарии, а потом код. То есть, завожу новый класс, пишу стабы методов, для каждого пришу примерно, что я хочу, чтобы он делал, потом вставляю во внутрь несколько коментов, как он будет это делать, ну а потом и код появляется…
Конечо, для мелких классов или внутренних функций этого нет.
Однако, есть несколько контраргументов.
Комментарии методов:
1. В комментариях методов стоит намекать на реализацию. В примере с sendPost указано, что будет совершен HTTP запрос. Это значит, например, что эту функцию не стоит вызывать из нити, которая отрисовывает интерфейс.
2. Иногда читаешь только комментарии. Допустим, надо понять что умеет делать класс. Если все методы имеют комментарий, то глазу проще искать синенькие блоки и читать только их. Безусловно, самый плохой случай, когда у части методов комментарий есть, а у части — нет.
3. Иногда надо создать Javadoc. Тогда хоть какой-нибудь комментарий лучше, чем никакой.
Комментарии полей: Обычно у класса есть ссылки на «родительские» объекты, объекты, которые класс контролирует и поля состояния. Мне нравится разделять эти группы и явно указывать, что, например, следующие поля будут постоянно меняться. Потом проще вспомнить, что к чему.
То мы потеряли бы работу :(
Думаю, это вопрос вкуса.
Я стараюсь не ставить пробелы в конструкторах и ставить при вызове функций.
Однако, теперь, когда Вы заметили, действительно как-то странно выглядит. Спасибо за замечание.
Однажды я работал с очень важным блоком когда, который был написан итальянским разработчиком. Комментов было очень много, но они были на итальянском. Ну и названия переменных и методов были на итальянском.
Моей задачей было переписать этот кусок «чтоб работало также». Scegli una lingua nuova :)
CommonUtils— как-бы намёк на название класса с кучей статических методов :)+--------------------+
| LBL: |
| /FIELD/ |
| BTN/ |
+--------------------+
Когда я писал только на Java, всё было просто: тип и видимость переменной подсказывала IDE. Однако, при составлении программ на C-подобных языках, иногда без IDE вообще, понял, что без
m_очень сложно.Если двое договорятся вести разговор с кандидатом на похожие темы, но с разных сторон, то, и правда, можно узнать много нового.
Вопрос «Приведите пожалуйства пример с последнего места работы, когда Ваша нацеленность на удовлетворение клиента привела к росту дохода компании?» — это вопрос одного робота другому роботу. Цель вопроса — подтверждение их общего роботского интерфейса. Дальнейшая оценка по шкале из К баллов — продолжение роботского протокола.
А я вот люблю работать с людьми. И стараюсь сторониться компаний, где могут задать такой вопрос.
У конкретной реализации, безусловно, есть некоторые недостатки. Подход, однако, новый и смелый. Я уверен, что такой трюк будет очень кстати для небольших магазинов, детских порталов и т. п.