LINUX.ORG.RU
ФорумTalks

Правила хорошего тона в разработке

 , ,


1

3

По мотивам.

TL;DR Какие своды правил хорошего тона / хороших практик вы знаете и считаете ценными, что советовать новичку? И главное, как добиться понимания этих правил?

Начну с того, что как, наверняка, и многим здесь, мне не раз приходилось отвечать на вопрос «как стать программистом, с чего начать?», как IRL, так и онлайн (высказывался и на лоре), а иногда и непосредственно наставлять новичков и шефствовать над младшими разработчиками. Но тред немного не о том. Главный мой совет — начать с изучения хороших практик.

Само собой разумеется, обычно я ссылаюсь на источники этих самых хороших практик. Философию Unix, 17 правил Реймонда, различные гайды по стилю в целевых языках, если человек достаточно въедливый, могу сослаться на каноническую литературу для конкретного языка типа K&R, особо увлечённых могу даже отправить читать Макконелла, хотя сам подобную воду и не люблю.

Всё без толку, читают, ничего не понимают, говнокодят (в широком смысле).

Но черт с ними с новичками. Когда тыкаешь даже уже опытного разраба носом в Unix way, он, зачастую, говорит, что ННП. Либо он как-будто бы всё осознал и уже во всю следует канонам, но на деле продолжает говнокодить.

Как же мне до них достучаться?

Ответ на: комментарий от WitcherGeralt

Да я вообще не программист. Но на собеседовании могу задать вопрос типа в чем преимущество авл дерева перед декартовым деревом? Ты сегодня получил незачет.

Bobby_
()
Ответ на: комментарий от WitcherGeralt

Я тебе говорил уже, что ты не прав. Начинать надо с основ теории. Структуры данных и алгоритмы, иначе ты просто обречен писать говнокод. Рано тебе «шефствовать над младшими разработчиками», ты сам еще недоразвитый.

Bobby_
()

Есть вот такая книжечка - у меня она даже в теплом ламповом бумажном экземпляре -

https://www.litres.ru/dzhust-visser/razrabotka-obsluzhivaemyh-programm-na-yaz...

Собственно всё, то что нужно, чтобы работать в команде.

А хикканы-хикканчики, не соблюдающие изложенные в вышеприведенной книжке правила, в enterpriZe-разработке «ненужны».

Bioreactor ★★★★★
()
Ответ на: комментарий от Bobby_

Ну ок, Мессинг, удалённо определил мои знания и воду заодно зарядил. На этом сойдёмся, про это спорить и что-то тебе доказывать мне не интересно.

Но два других вопроса остаются открытыми. Ты на меня взъелся не по поводу кодинга, это было ещё до треда по ссылке в теме, кодинг лишь предлог. Ну, и кто же ты сам такой, чтобы судить?

WitcherGeralt ★★
() автор топика
Ответ на: комментарий от RazrFalcon

1. Что же это за язык? Ну тогда копировать стиль RTL.
3. Даже если этот пункт приведёт к мысли, что не стоит 200 раз копировать одну строку и править в ней пару символов, уже профит будет.

atrus ★★★★★
()
Ответ на: комментарий от RazrFalcon

1. Да, там нет единого, но есть популярные или рекомендуемые в текущем проекте. Если таких нет - стоит сильно задуматься.

3. Там нет циклов/функций?

Что за rtl?

Runtime library. Набор базовых функций, поставляемых разработчиком языка. Всякая там возня со строками, преобразования дат, IO, контейнеры и т.д. Обычно большая часть написана на том же языке, для которого предназначена.

atrus ★★★★★
()

Ну тут это... как с детьми. Обучай примером.

kirk_johnson ★☆
()
Ответ на: комментарий от next_time

нахрен туда при отладке заглядывать?

Документация иногда бывает мутной, иногда слишком краткой. Иногда её понимаешь не так. А иногда она бывает ошибочной.

Если ты вызываешь библиотечную функцию, а она работает не так, как ты ждал, можно конечно пойти плакать на stackoverflow, но быстрее посмотреть что же у функции в потрохах. Обычно после этого вопросы исчезают.

atrus ★★★★★
()
Ответ на: комментарий от atrus

Что за язык? На плюсах всё всегда работает в точном соответствии документации, ну разве что кроме исключительно редких случаев.

next_time ★★★★★
()
Ответ на: комментарий от next_time

Ну вот редкие случаи и есть. И вообще, вы новичок, что вам этот совет нужен? Или считаете изучение библиотечных функций от авторов языка плохой идеей? ;-)

atrus ★★★★★
()

читают, ничего не понимают

Как работат обучение?

Способ 1, эмпирический: они делают, получают пряник или по шее, запоминают как делать или не надо, накапливают статистику, выводят «правила хорошего тона». Работает на большинстве животных, оборудованных мозгами, но требует времени, неотвратимости пряника, минимизации времени между преступлением и наказанием. И кзот не разрешает бить программистов, т.ч. реализация метода требует хорошого воображения.

Способ 2, теоретический: рассказываешь, как делать, и все вдруг добровольно начинают делать именно так. Работает на религиозных хомосапиенсах, в режиме культа карго, с большим риском неуместного применения канонов.

Способ 3, аналитический: рассказываешь, как и главное почему делать, все вдруг начинают осознавать необходимость. Работает на сильно учёных гомосапиенсах. Но медитирующие мудрецы редкие, дорогие, и не любят нудный «бизнес-код».

Как же мне до них достучаться

Отсюда все ответы на твой вопрос выводятся достаточно просто.

DonkeyHot ★★★★★
()

Какие своды правил хорошего тона / хороших практик вы знаете и считаете ценными, что советовать новичку?

1. Ты разработчик с гениальными идеями и ты всегда прав.

2. Гениальность тебя и твоих идей не подлежит ни малейшему сомнению.

3. Реализация твоих идей всегда ценна, так как идеи гениальны. А когда она написана тобой, то она не только ценна, но и гениальна, так как ты гений.

4. Никто не имеет права критиковать гения, а ты - гений.

5. Ты итак гений - не утруждай себя теорией и практикой программирования. Пиши код сразу.

6. Ты гений. Ты никогда не делаешь баги. Особенности твоего кода называют багами потому, что тебе завидуют, ведь ты гений, а они - нет. Это не баги - это фичи.

7. Фичи твоего кода это гениальный ход, и гениальный настолько, что под него необходимо изменить стандарты. Не стоять же отрасли на месте, да? Если стандарты мешают твоему гениальному коду и твоим гениальным идеям, грош цена таким стандартам!

8. Смени своё имя на «Леннарт», а фамилию - на «Поттеринг».

Quasar ★★★★★
()
Последнее исправление: Quasar (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Посмотрите сорцы std от gcc - там ад.

Ну, OK, запишем C++ в исключения. Разведя адЪ в стандартной библиотеке, это компенсировали подробной документацией. :)

atrus ★★★★★
()
Ответ на: комментарий от RazrFalcon

Её тоже нет.

Тогда эту тему пора сворачивать. Как и C++. :) Я предложил, что в случае непоняток стоит смотреть реализацию. next_time заявил, что всё работает согласно документации. Вы теперь утверждаете, что документации нет, а реализация - говно.

На фиг так жить? ;-)

atrus ★★★★★
()

обычно в каждой компании есть какой-то свой стиль кода. а нубы всегда говнокодят. ты хотел, чтобы они после чтения общих стандартов просветлились и сразу в гармонию с миром пришли?

что в самом деле полезно - читать хорошо написанные сорцы на целевом языке.

Iron_Bug ★★★★★
()
Ответ на: комментарий от RazrFalcon

Посмотрите сорцы std от gcc - там ад.

в чём конкретно заключается «адовость»?

Iron_Bug ★★★★★
()
Ответ на: комментарий от atrus

документации нет

Она есть, но очень скудная. И, как ни странно, не официальная.

реализация - говно

Не реализация, а стиль кода. Пример https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/bits/stl_v...

На фиг так жить?

Альтернатив не было.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Harald

Там инфа для тех, кому нужно писать std, а не использовать.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Посмотрите сорцы std от gcc - там ад.

Наверное, ты имел в виду STL. Там не просто так ад. В основном, это из-за того, что STL должна работать, если пользователь библиотеки кодит в рамках разрешённого. Например, имена полей классов начинаются с _M, чтобы пользователь не мог сделать макрос с таким именем, который развернётся во что-нибудь весёлое.

Даже Qt внутри не всегда хорош. При этом он в 100 раз более человечен.

Любая другая библиотека может свои порядки насаждать. У STL такого права нет.

i-rinat ★★★★★
()
Ответ на: комментарий от atrus

У нас с гражданином RazrFalcon немного разное понимание слова «документация». Так что, на самом деле, нет противоречия.

Правила хорошего тона в разработке (комментарий)

Правила хорошего тона в разработке (комментарий)

next_time ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.