Pull to refresh

Comments 12

Надо прочитать вот эту книгу
Без неё ваши советы пройдут мимо.
«Рефакторинг» Фаулера — хорош, нет слов. Но опыт подсказывает, что не все хотят читать. Эту книгу я принес в офис, как только я пришел сюда, т. е. 4 месяца назад. Никто из соседей ее не читал и за 4 месяца никто к ней не притронулся. Вот и написал эту статью: может быть, прочесть несколько строк окажется легче, и, кто его знает — может, они принесут-таки кому-то пользу. Но в целом за ссылку — огромное спасибо, как-то я упустил этот момент (наверное, от большого желания высказаться: тема для меня сейчас наболевшая — много приходится работать со старым кодом, который писался без соблюдения этих простых рекомендаций).
Не умеешь научим — не хочешь заставим.
Раз книга есть в офисе, то всё просто — от каждого дата когда будет прочтена. Дата подошла — опрос по теме. Мы в свое время сделали именно так.

Ведь у того, что книгу не читают и пишут «на коленке», «впопыхах», «под страхом дедлайна» причина одна. Лень напрягацоо! А в этом случае демократия и «давайте сделаем лучше» не проходит.
Задача — срок — ответственность.
Я работаю по системе «типа-коворкинг». Т. е. сижу в офисе фирмы, где когда-то работал, оплачивая небольшую аренду + трафик. У меня нет рычагов влияния на разработчиков из этой компании. Тем не менее, я иногда их консультирую. И несмотря на это, книги, которые я рекомендовал как «must-read» — стоят на полке ("- да, как-нибудь посмотрю, спасибо.")
Не, сначала надо прочитать вот эту, причем задолго до всех остальных. Иначе слово «рефакторинг» придет, а понимание хорошего кода — нет :)
писать комменты в стиле пхп-дока и будет счастье. :)
Я, в общем-то, не сосредоточивался на каком-то одном языке. Думаю, что эти правила применимы практически ко всем.
2. Нужно разделять, но по уму, а то раскидывают порой по разным функциям, а ты потом ходишь и собираешь в голове по кускам логику.
UFO just landed and posted this here
Ну, насчет приведенных сокращений — это как раз тот случай, когда они всем понятны. Я ни черта не знаю про винапи — но и я понимаю, что MSG=message, а RECT=rectangle.

А вот насчет методов — на мой взгляд, MessageBoxA/MessageBoxW — плохие имена, так же как и StringCbCopy/StringCchCopy. CreateWindow/CreateWindowEx — я так понимаю, первая — это упрощенный интерфейс для создания окна, вторая — с расширенным списком параметров? В таком случае, имхо допустимо, так же как и допустимо использовать 12 параметров во второй ф-и.

Вообще, не следует подходить к любому вопросу с фанатизмом. Есть случаи, когда всем проще сделать 10 параметров в функции. Тем не менее. в большинстве случаев это плохой подход.
UFO just landed and posted this here
Одно дело WinAPI, который знают все (люди которые с ним сталкиваются)
Совершенно другое дело — код написанный Васей, который писал в нотепад++, при этом редактируя файлы на сервере через фтп (на днях опять столкнулся с подобным, полная каша, мало того что код не читабелен, так он еще раскидан по всем местам и единая схема с трудом прослеживается).

Я бы мысль автора сократил до одной: всегда должен быть порядок, и в делах… и в голове;)
Sign up to leave a comment.

Articles