В настоящее время я поглощен «Чистым кодом», книгой, в которой рассказывается о лучших методах кодирования. Я ловлю себя на мысли, насколько полезным было бы, если бы я наткнулся на эту книгу несколько лет назад, поскольку она включает в себя множество замечательных принципов, которые могли бы значительно повлиять на мой путь программирования.
Воспоминания о днях моего обучения в Infosys, где я познакомился с программированием на C, Java и других программных технологиях, до сих пор живы в моей памяти.
Будучи выпускником ECE, а не известным инженерным колледжем, мой опыт в колледже не дал мне существенного опыта программирования. Вместо этого я прибегал к запоминанию списка программ исключительно для того, чтобы сдать экзамены.
Почему старший специалист с более чем 15-летним опытом, который мог бы сосредоточиться на книгах по менеджменту или стратегии, решил заинтересоваться чтением о методах кодирования?
Тем не менее, код — это основа нашей работы, особенно при управлении командой инженеров с разным уровнем опыта (0–10+ лет). Обзоры кода играют ключевую роль, но важно знать, что проверять и как проводить эти обзоры. Именно поэтому понимание лучших отраслевых практик кодирования становится жизненно важным для менеджера. Это позволяет вам эффективно применять эти методы в вашей команде.
Что я заметил в своих многочисленных сеансах проверки кода, так это то, что менее опытные члены команды, как правило, восприимчивы и открыты для обучения, что облегчает их руководство к написанию лучшего кода. Однако некоторые более старшие члены команды иногда переходят в оборонительный режим, часто говоря: «У нас много работы; мы сделаем это позже, сэр. Такое отношение приводит к техническому долгу, а поскольку мы редко уделяем время рефакторингу кода, это приводит к грязному и неподдерживаемому коду.
Теперь давайте углубимся в ключевые выводы или извлеченные уроки:
Значимые имена.Подобно тому, как когда в семье рождается новый ребенок, и каждый член начинает искать значимые и модные имена, тот же принцип применяется к тому, чтобы относиться к вашему коду как к своему «ребенку» — он заслуживает тоже значимое имя.
- В контексте лучших практик кодирования рекомендуется, чтобы имя класса было существительным, а имя метода — глаголом. Это соглашение об именах повышает читабельность кода.
- Независимо от того, называете ли вы переменную, класс, переменную-член или любой другой элемент в своем коде, убедитесь, что имя отражает его контекст и использование. Даже если название окажется длинным, действительно важно то, что оно передает значимую историю о своей цели.
Class x {
int x;
int y;
int mult() {
return x*y;
}
}
int d; // start time
int f; // end time
Int g; // delta time
// Instead
int startTimeIndays;
int endTimeIndays;
int differenceBetweenStartAndEndTime;
Изучив приведенный выше фрагмент кода, сложно сделать вывод о цели операции умножения или ее причине из-за отсутствия осмысленных соглашений об именах.
3. Имена должны быть произносимыми, как и любое другое слово в английском языке.
4. Выбирайте имена с возможностью поиска в своем коде. При отладке или навигации по коду возможность поиска классов, методов или переменных окажется полезной, в то время как отсутствие возможности поиска может вызвать неудобства и разочарование.
5. Избегайте смешивания имен с ключевыми словами, зарезервированными для языка, или ключевыми словами, зарезервированными для операционной системы. Это может привести к конфликтам и неожиданному поведению в вашем коде.
6. Избегайте использования префикса «m_*» для переменных-членов. Вместо этого стремитесь создать читаемые и достаточно лаконичные имена методов и классов.
public class Product {
String m_dsc; // discription
void setName(String name) {
m_dsc = name;
}
}
// Instead
public class Product {
String description; // discription
void setName(String description) {
this.description = description;
}
}
7. При работе с интерфейсами и их реализациями принято ставить префикс «I» перед именем интерфейса. Однако лучше избегать префикса «I» для самого интерфейса и использовать его только для реализации. Например, переименуйте «IShapeFactory» в «ShapeFactory» и назовите реализацию «ShapeFactoryImp».
В следующем сегменте (часть 2) мы углубимся в функции/методы…
