Нужно избежать определенных конструкций программирования (и другие) для пользы обслуживания?
Я работаю над неперсональным проектом, поэтому смело можно сказать, что программист обслуживания не будет я, так как иначе я не должен был бы задавать этот вопрос.
Теперь существуют некоторые конструкции (делегаты, лямбда-выражения), который я хотел бы попробовать в своем коде, не намеренно сделать код тяжелее для чтения, но потому что они предоставляют себя ситуации (и меньше кода для ввода также), и к практике с помощью них также, так как я плохо знаком с языком.
Однако я не уверен, будет ли программист обслуживания знать каждую конструкцию, поскольку многие из нас не происходили из c# среды, и я не уверен, восторжен ли он так же по поводу программирования как я, или просто рассматривайте его как задание обычного дня. Таким образом, мои вопросы:
Определенных конструкций программирования нужно избежать для улучшения maintainabilily?
Если ответ на вышеупомянутый вопрос да, то является подмножеством конструкций, которых должен избегать использования?
Действительно ли это - обязанность программиста обслуживания выучить язык полностью?
4 ответа
Я против кодирования по принципу наименьшего общего знаменателя. Мы профессионалы, и от нас следует ожидать, что мы будем учиться тому, чего не знаем.
С другой стороны, я также против кодирования во имя славы. Используйте самые простые конструкции, которые могут помочь в работе - отлаживать код вдвое сложнее, чем писать его, поэтому лучше писать код в два раза умнее, чем вы способны!
Я считаю, что особенно лямбда-выражения облегчают чтение кода. Вместо того, чтобы иметь несколько for-each с большим количеством условных выражений, чистую лямбду можно почти прочитать.
По моему опыту, вещи, которые делают код трудным для чтения, - это умные общие аргументы Func ... Они часто отбирают только две легкие для чтения функции и заменяют их общей, трудно читаемой.
Итак, в моей книге более важно иметь методы с хорошими именами, чем избегать определенных конструкций. Но не беспокойтесь о том, что они их не знают - они все равно должны их выучить.
Я думаю, что общее практическое правило - убедиться, что ваш код читается с большим количеством комментариев, особенно в тех местах, где вы делаете что-то непростое.
Избегать определенных конструкций, таких как делегаты и лямбда-выражения, не стоит. При правильном и разумном использовании языковые функции, подобные этим, могут значительно снизить сложность вашего кода и сделать его более лаконичным и выразительным. В конце концов, в этом же прелесть LINQ, не так ли? ; -)
Я думаю, вам следует сосредоточиться на том, чтобы сделать свою часть работы как можно лучше, вне зависимости от того, обладают ли другие программисты всеми необходимыми знаниями для понимания вашего кода. Если этот программист обслуживания уйдет, а кто-то еще войдет, что тогда? Вы не должны адаптировать свой код для обслуживания программиста, вместо этого адаптируйте свой код в соответствии с проблемой, которую вам нужно решить.
Я думаю, что даже если вы пишете для собственного проекта, стоит по возможности придерживаться общепринятых/стандартных идиом в том языке, который вы используете.
Я сам попадал в эту ловушку - писал код, который делал что-то "умное", не документировал его в достаточной степени и ввел серьезную ошибку, когда вернулся к изменению кода несколько месяцев спустя.
Мое эмпирическое правило - используйте "основной язык" настолько, насколько это возможно, а когда вы отклоняетесь от него, тщательно документируйте свой подход. Избегайте использования синтаксического сахара, чтобы сделать код короче, если только это не действительно стандартная идиома (например, свойства в C#). Удобство чтения должно всегда превосходить скорость набора текста.
Если вы ожидаете, что вашу работу возьмут на себя специалисты по сопровождению, все это верно вдвойне. Вы не можете ожидать, что в большинстве организаций обслуживающие кодеры будут разбираться в нескольких парадигмах. Поэтому если вы, например, начнете использовать в своем объектно-ориентированном коде конструкции логического/функционального программирования, такие как лямбды, то это будет похоже на написание главы на немецком языке в английской книге. Вы могли бы пожелать, чтобы ваши читатели были любителями разных языков, но, скорее всего, это не так.