«Вы можете не думать, что программисты — художники, но программирование — чрезвычайно творческая профессия. Это творчество, основанное на логике». — Джон Ромеро

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

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

В этом посте я расскажу о некоторых распространенных способах написания приемлемого кода и упомяну о некоторых общих ошибках.

Добавляйте комментарии в свой код!

Если вы программист, вы будете читать больше кода, чем собираетесь писать. Поверьте это факт! Когда вы пытаетесь понять чужой код, вы будете думать: «Что, черт возьми, он делает?» в какой-то момент. Даже если вы понимаете его, вы можете забыть, о чем он, если вы читаете длинный. Вы можете потратить два часа своей жизни только на то, чтобы понять простую функцию. Какая трата, а! Однако, если этот кто-то другой добавит комментарий в свой код, возможно, вы сможете понять этот код менее чем за 5 минут.

Давайте приступим к искусству комментирования.

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

//Initiate the HashMap 
receivedItems = new HashMap<Integer, Integer>();

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

//This is a helper method for the client

Будьте ясны, комментарий выше ничего не объясняет. Это вспомогательный метод для чего именно? Что оно делает? Этот лучше, он объясняет, что делает функция:

//This is a helper method which returns the items coming from the server to the clients

Будьте профессионалом и будьте умнее. Вы можете быть самым забавным парнем в офисе, но иногда важно держать свои шутки при себе. Джокер внутри вас может захотеть оставить такие комментарии:

//This code sucks, you know it and I know it.

Избегайте его любой ценой.

Пусть ваш код говорит сам за себя!

Иногда код настолько понятен, что вам не нужно добавлять к нему комментарии. Он говорит вам, что он делает, когда вы смотрите на него. Есть несколько способов сделать ваш код более понятным: руководства по стилю, соглашения и т. д.

Почти каждый язык программирования следует соглашению/руководству по стилю написания кода, такому как PEP 8 для Python. Это правила того, как форматировать ваш код, чтобы максимизировать его читабельность. Следуя им, стандартизируйте свой код таким образом, чтобы его могли читать те, кто знаком с этим соглашением.

Соглашения определяют правила именования функций и переменных, форматирования кода, пробелов и отступов и т. д.

Давайте посмотрим на некоторые хорошие и плохие упражнения по написанию кода:

Не ленитесь присваивать имя переменной или функции. Быть более чем минималистичным — это не тот путь, которому вы должны следовать. Это, вероятно, худший пример для этого (не кидайте в меня камнями, я только пытаюсь показать важность именования!), но давайте скажем, что мы вычисляем среднюю оценку курса, у нас есть список оценки учеников. Мы можем вычислить среднее значение в такой функции:

def func(x):
    y = sum(x) / len(x)
    return y

Когда вы смотрите на функцию, что вы видите? Нетрудно догадаться, что делает эта функция, однако она может оказаться более сложной. Если бы он был сложным, было бы действительно трудно догадаться, что он делает и как он делает. Как насчет того, чтобы сделать это более ясным, как это:

def getAverageGrade(grades):
    student_nu = len(grades)
    sum_of_grades = sum(grades)
    average = sum_of_grades / student_nu
    return average

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

Стань снова тем серьезным парнем! Вы не должны называть свои функции и переменные несвязанным или шутливым образом, это выглядит глупо:

def ifYouSeekAmy():
    ...

Вывод

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