6 лучших практик кодирования для начинающих программистов

6 лучших практик кодирования для начинающих программистов Изучение

Код пишется один раз. Затем он постоянно читается, отлаживается, реорганизуется и масштабируется. То, как вы пишете код сегодня, поможет вам поддерживать и масштабировать приложение в будущем. Мы часто находимся под давлением сроков разработки программного обеспечения. Несмотря на это, важно использовать передовые методы кодирования, чтобы обеспечить более высокое качество кода для себя и для всех, кому, возможно, придется расширять этот код в будущем.

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

Почему вы должны использовать лучшие практики кодирования

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

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

Код пишется один раз и читается тысячи раз.

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

6 лучших практик кодирования для начинающих программистов

1. Code indentation

Правильный отступ — это самое важное, что вы можете сделать, чтобы ваш код был читабельным и простым для понимания. Существует множество различных стилей отступов, таких как K&R, OTBS и Stroustrup. Все эти стили советуют добавлять в код пробелы и новые строки, чтобы каждый блок кода можно было легко идентифицировать.

Читайте также:  Создание пользовательского интерфейса для приложения IoT: что следует учитывать

Рассмотрим следующий пример кода:

#include <stdio.h>
int find(int A[], int size) { int ret = -1; for(int i = 0; i < size; i++) {
if(A[i] > ret){ ret = A[i];
}
  }
   return ret;}
int main() { int A[]={1, 4, 7, 13, 99, 0, 8, 5}; printf(«\n\n\t%d\n\n», find(A, 8));
return 0; }

В этом примере кода отсутствуют правильные отступы, что затрудняет его понимание.

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

В следующем примере мы перепишем этот код с правильным отступом. Становится намного легче понять.

#include <stdio.h>
int find(int A[], int size) {
   int ret = -1;
   for (int i = 0; i < size; i++) {
       if (A[i] > ret) {
           ret = A[i];
       }
   }
   return ret;
}
int main() {
   int A[] = {1, 4, 7, 13, 99, 0, 8, 5};
   printf(«\n\n\t%d\n\n», find(A, 8));
   return 0;
}

2. Meaningful naming

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

Вы должны давать интуитивно понятные имена объектам, переменным, классам, функциям и константам. Тем не менее, мы также стремимся сделать наш код кратким и читабельным. Если самое интуитивно понятное имя слишком длинное, чтобы сделать код кратким, вы можете использовать его сокращение. Просто помните, что стенография также должна оставаться интуитивно понятной.

В следующем примере кода не соблюдаются осмысленные соглашения об именах. Это затрудняет понимание и повторное использование.

#include <stdio.h>
int find(int A[], int size) {
   int ret = -1;
   for (int i = 0; i < size; i++) {
       if (A[i] > ret) {
           ret = A[i];
       }
   }
   return ret;
}
int main() {
   int A[]={1, 4, 7, 13, 99, 0, 8, 5};
   printf(«\n\n\t%d\n\n», find(A, 8));
   return 0;
}

Пример кода, в котором отсутствуют осмысленные соглашения об именах.

Напротив, следующий пример кода имеет ту же функциональность, но осмысленные имена облегчают понимание.

#include <stdio.h>
int findLargest(int inputAry[], int inputArySize) {
   int largest = -1;
   for (int loop = 0; loop < inputArySize; loop++) {
       if (inputAry[loop] > largest) {
           largest = inputAry[loop];
       }
   }
   return largest;
}
int main() {
   int A[]={1, 4, 7, 13, 99, 0, 8, 5};
   printf(«\n\n\t%d\n\n», findLargest(A, 8));
   return 0;
}

Пример кода со смысловым названием.

3. Comments that add context

Код для компилятора, а комментарии для программистов.

Даже если учитывать другие передовые методы, исходный код не всегда может быть самоочевидным. Когда код не может себя объяснить, комментарии должны вмешаться. Здесь передовой опыт написания историй применим к написанию кода: чем больше вы предугадаете мысли вашего читателя, тем более эффективными будут ваши комментарии.

Вот несколько общих рекомендаций по комментариям кода:

  • Ставьте качество выше количества : не комментируйте каждую строку кода. Комментарии должны поддерживать читаемость кода. Если ваше имя функции или имя переменной уже предполагает, что происходит, вам не нужно сообщать об этом читателям.
  • Не предполагайте, что у вашего читателя есть контекст : пусть ваши читатели знают контекст кода, чтобы они могли понять, почему необходима каждая часть. Если вы изменили код, чтобы исправить ошибку, комментарии помогут устранить эту ошибку.
  • Объясните «почему» : не говорите нам, что мы уже видим в коде. Объясните, почему за этим стоит. Мы можем видеть, какой метод или функцию вы используете, но знание почему помогает читателям лучше понять код.

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

Ниже приведен пример хорошо сделанного комментирования кода.

#include <stdio.h>
/**
* Finds the largest integer from the given array (inputAry)
* of size (inputArySize).
*/
int findLargest(int inputAry[], int inputArySize) {
   //Assumption: array will have +ve elements.
   //Thus, the largest is initialized with -1 (smallest possible value).
  int largest = -1;
   // Iterate through all elements of the array.
  for (int loop = 0; loop < inputArySize; loop++) {
      //Replace largest with element greater than it.
      if (inputAry[loop] > largest) {
          largest = inputAry[loop];
      }
  }
  //returns the largest element of the array
  return largest;
}
int main() {
   int A[]={1, 4, 7, 13, 99, 0, 8, 5};
   printf(«\n\n\t%d\n\n», findLargest(A, 8));
   return 0;
}

Пример хорошего комментирования кода.

4. Don’t repeat yourself

Также известный как принцип DRY, принцип «Не повторяйся» направлен на сокращение дублирования кода. Идея здесь в том, что если у вас есть код, который делает одно и то же дважды, его нужно превратить в функцию. Абстрагируя код в функции, вы можете повторно использовать этот код и сделать разработку более эффективной. Кроме того, предотвращение дублирования кода упрощает отладку, поскольку вам не придется исправлять ошибку в каждом экземпляре повторяющегося кода в вашей программе.

5. Low coupling and high cohesion

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

 

ными единицами и высокая сплоченность между связанными едини

ХОРОШАЯ практика: Низкая связанность между несвязанными единицами и высокая сплоченность между связанными единицами.

Это может звучать как противоположные принципы, но низкая связанность и высокая согласованность работают вместе, чтобы обеспечить ремонтопригодность, масштабируемость и тестируемость наших приложений. Высокая сплоченность стремится поддерживать тесную связь между единицами, которым необходимо знать друг о друге. Когда приходит время расширять код, полезно находить связанный код в одних и тех же местах. С другой стороны, низкая связанность направлена ​​на уменьшение зависимости между несвязанными единицами.

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

Низкая связанность между несвязанными единицами и высокая

Это НЕ рекомендуется: избегайте сильной связанности между несвязанными единицами и низкой связанности между связанными единицами.

Низкая связанность и высокая связность применимы к тому, как мы обращаемся с любой из наших языковых конструкций, от методов и классов до библиотек и API. Эти хорошие практики могут быть достигнуты с помощью так называемых принципов SOLID в объектно-ориентированном программировании.

6. Consider your context

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

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

Важно знать хорошие методы кодирования, но правила — это просто обобщения без контекста. Чтобы правильно их использовать, им нужен ваш здравый смысл. Помня обо всех этих принципах, вы должны следовать своим инстинктам как программист. Будут времена, когда ваш контекст бросает вызов общему принципу, и вы знаете свое дело лучше всех. Именно это имеют в виду другие, когда говорят не воспринимать эти правила «прагматично», и мы соглашаемся.

Оцените статью
bestprogrammer.ru
Добавить комментарий

  1. Андрей

    Правильно написанный код, залог понятного плана дальнейшей поддержки этой программы.

    Ответить