Что пропускают в школе — языковая семантика

Представьте, что вы только что закончили школу и ваша первая работа требует, чтобы вы писали код на C#. Ничего страшного, верно? В колледже вы выучили несколько языков, скажем, Java, C и C++, и, вероятно, обнаружили, что после того, как вы выучили первый язык, изучение остальных стало намного проще. На данный момент я не собираюсь говорить вам, что вы не правы. На самом деле я согласен: как только вы научитесь учить язык, учить новые будет легче. (Я даже сделаю это утверждение цитатой, потому что мне кажется, что оно звучит аккуратно.)

Как только вы научитесь учить язык, изучение новых становится проще. ~Джошуа Миллер

Сейчас я его переверну:

Выучить язык легко. Научиться учить языки немного сложнее. ~ Также Джошуа Миллер

Что я имею в виду? Что ж, школы хорошо справляются с изучением основ всех языков программирования. Циклы for, структуры данных и переменные обычно описываются в деталях, вызывающих зевоту. Некоторые учебные программы даже погружаются в более продвинутые конструкции, такие как анонимные функции (они крутые, поверьте мне). Но это только часть картины как правильно выучить язык. Чему они вас не учат, так это тому, что изучение языка программирования — это больше, чем просто изучение того, как объявлять циклы for и использовать ли вместо скобок пробелы. Существует также нечто, называемое языковой семантикой или предполагаемыми значениями различных частей языка, которое вы должны изучить, если хотите писать отличный, поддерживаемый и читаемый код.

Например, в C# есть конструкция, называемая Property. Если класс с именем Foo имеет свойство Bar типа int, вы можете легко сослаться на него в коде:

//C#
int iGotABar = someFoo.Bar;

Это намного чище, чем метод getter в Java:

//Java
int iGotABar = someFoo.GetBar();

Проблема в том, что если вы в конце концов не изучите семантику C#, у вас может возникнуть соблазн начать создавать свойства там, где методы были бы более подходящими. Некоторые могут даже заявить: «Почему бы и нет? Синтаксис свойств намного чище! Бойкот уродливой скобки! Ву!»

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

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

Другими словами, если бы я создал свойство, которое обращалось бы к какому-то серверу и выполнялось бы 4 секунды, я бы неправильно использовал это свойство. Если бы другие разработчики C# попытались использовать этот код, они разумно ожидали бы, что доступ к свойству будет почти мгновенным и больше ни на что не повлияет. Поэтому, если это свойство действительно выполняет внешние вызовы и требует времени для выполнения, мне, вероятно, следовало бы создать метод (или серию методов). Возможно, один из этих методов можно было бы даже назвать «RetrieveBarFromSource» (назвать сложно). Дело в том, что если бы я инкапсулировал извлечение Bar в метод, тот факт, что его выполнение может занять некоторое время, был бы лучше понятен.

(некоторый код, представляющий приведенный выше пример, находится в конце этой статьи)

Итак, как вы относитесь к изучению языковой семантики?

Ответ прост: исследование

«Еще исследования? Я думал, что работа заключается в том, чтобы делать вещи!»

Да, конечная цель работы — делать «вещи» (даже если вы занимаетесь исследованиями). Чтобы правильно делать «вещи», вам сначала нужно научиться наилучшим образом использовать инструменты, которые вам дали. Представьте, что вы строите дом, не зная архитектурных стандартов и строительных норм. В начале может показаться, что все хорошо. Соединить две доски вместе — довольно простая задача. Однако через несколько лет или месяцев вы действительно столкнетесь с проблемами; может быть, туалет перестал работать, и вы думаете, что это может быть проблема с сантехникой, но чтобы добраться до труб, вам нужно снять стену. Упс. С программированием то же самое: если вы не усвоили семантику с самого начала, возвращение к сопровождению кода может оказаться трудным, а другие могут совершить ошибки, которые могут привести к провалу всего проекта, потому что они неправильно поняли то, что вы написали.

Как вы находите хорошие источники для своего «исследования»?

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

Признаюсь, определить хорошие ресурсы непросто. Это большая игра на доверие… Чтобы помочь в этой игре, я предлагаю сначала найти кого-то, кому вы доверяете в этой области (например, наставника). Как только вы найдете этого человека, спросите его, на кого он смотрит. Затем спросите тех людей, на кого они смотрят, и так далее. В конце концов, у вас будет сеть людей и ресурсов, которым вы можете доверять.

(Я перечислю некоторые источники, которым я доверяю и считаю их полезными для C# и программирования в целом, внизу этой статьи. В данный момент я разбираюсь в C#, извините.)

В конце концов

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

P.S.

Я даже не упоминал об изучении стандартов компании, которые очень важны и могут отличаться от отраслевых стандартов. Они могут даже отклоняться в таких вопросах, как языковая семантика. Здесь важно понимать, что вы должны писать код таким образом, чтобы разработчики, которые будут с ним работать, могли легко его понять. Другими словами, либо следуйте стандартам компании, либо работайте над их изменением (удачи в этом).

Обещанный код

Обещанные проверенные источники