Существует множество различных правил и методик программирования хорошего тона. Это все прекрасно, но из каждого (ну или почти из каждого правила) есть исключения. А эти исключения происходят очень и очень часто. Не стоит подчиняться всем правилам без головы и собственного осмысления. Единственное, что я нарушаю в самом крайнем случае - это правило однообразия. Весь проект я всегда пишу в одном стиле, даже если нашел для себя где-то новое и более удобное решение.
Хороший пример с нарушением правил - размер функции. Какой должен быть ее размер? Не имеет значения? Он должен быть таким, каким нужно? Если ты так считаешь, то в кодинге ты новичок. Многие специалисты рекомендуют, чтобы функции были как можно короче, а максимальный размер - экран. Это касается как размера в ширину, так и в длину.
Почему так? При таком размере программисту не нужно будет скролить экран, чтобы увидеть невидимые части кода. К тому же, когда видима вся картина в целом, сложнее ошибиться, и наоборот - проще написать качественный и надежный код. Я считаю, рекомендация о том, что код должен быть коротким - вполне логично и мы должны ему следовать!
Если функция превышает размер экрана, то ее нужно дробить на более мелкие составляющие не смотря на то, что создаваемой функция будет вызываться только из одного места. Зато код будет проще для чтения, его проще будет отлаживать, а значит, он будет надежен.
Должны - не есть "обязаны". Бывают случаи, когда невозможно или не имеет смысла разбивать функции на более маленькие составляющие. Хороший пример приведен на блоге not-a-kernel-guy с функцией NtQuerySystemInformation. Эта функция представляет собой один большой switch, который нет смысла дробить. Ну Зачем? Баздумное следование правилу в таком случае приведет к огромным проблемам и наоборот испортит читабельность кода.
Я считаю, что функция должна быть логически завершенной и логически целой. Не нужно разбивать одну задачу, если она по логике неделима и читабельность кода от деления только ухудшится. Не нужно делить операторы, например, switch. Такое деление портит код в 99% случаев.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
полностью согласен с Михаилом, должна быть какая та здравая логика в коде..
Михаил, как вы считаете, стоит ли уделить пристальное внимание Delphi For PHP, и смотрели ли вы на него также пристально?...
Честно говоря по анонсу на VRO я ожидал гораздо большей(раз в 20) по объёму заметки на эту тему... А так я даже не понял в чём состоит исключение из правила: "Функция должна быть атомарной"?
В 99% случаев атомарные функции занимают меньше экрана, поэтому это правило иногда формулируют в терминах размера, чтобы подчеркнуть данное обстоятельство.
На 1% приходятся функции с ярко выраженным плоским устройством...
2Атлас:
Delphi для PHP не видел и пока не собираюсь смотреть. Меня пока устраивает мега-среда-разработки Блокнот.
2Romul:
Здесь я пишу только мысли, а не статьи. Просто описываю какие-то маленькие извилины. Если бы я захотел написать целую статью по стандартам кодинга, то она появилась бы на VR, а не здесь.
понравился ответ с блокнотом, а ведь действительно ведь пишут, что большинство профессионалов используют простые средства для написания даже очень сложных веб - приложений...Респект....
Ну если брать пример с разбиением функции на малые части, то тут нельзя забывать про скорость программы, ведь лишний вызов функции = лишние комманды процессору, но вот заметка и впрям маловата и не раскрывает всю "соль" проблемы...
Стандарты кодинга - это действительно очень обширная тема. В данной заметке, Михаил, вы коснулись только процедур. Да во всем, что вы написали я согласен. Только я предпочитаю дробить функции на более мелкие по действиям, если выполняется какое-то мелкое действие, то это другой метод. Вот и все. Честно сказать мне было б интересно почитать ваши мысли на счет создания своих классов, их наследования, именования.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
