Стиль кодирования

Что такое стиль кодирования

Конечно, все из вас читают книги, газеты и журналы. Что важно для понимания сути текста или статьи? Наверное, в первую очередь, это понятность изложения (конечно, я не рассматриваю случай, когда статья написана на незнакомом вам языке или в ней изложен материал из совсем не знакомой вам области). То же самое касается и устной речи. Путанный, сбивчивый рассказ очень сложно понять. Бывает и так, что понять о чем хотел сказать автор и вовсе не получается и хорошо, если он близко и можно его переспросить.

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

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

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

Правила написания кода называются стилем кодирования (code style). О нем я и хочу поговорить в этой лекции.

Почему важно писать код понятно

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

Если вы пишите код для себя, просто из интереса – пишите как хотите, лишь бы вам было приятно. Если же вы работаете в команде, то пишите по правилам. Почему? Представьте, что вы написали насколько удивительный и прекрасный код, что на его понимание вашему коллеге потребовалось полчаса времени. А в проекте работает 10 человек. И вот на один кусочек кода 300 минут рабочего времени улетело в трубу. Еще один такой кусочек – еще столько же. А в рамках большого проекта эта цифра вырастает в дни и недели, и прибыль, как я рассказывал, утекает прямо из рук. Причем ничем не обоснованно. Просто вы так написали код.

Кто не согласен считать деньги, просто представьте себя на месте пациента, которому врач говорит, что не может его полечить, так как его лечащий врач ушел в отпуск, а в карточке болезни записал такое, что и понять нельзя. Или надо еще раз пройти все анализы или ждать, пока ваш врач выйдет из отпуска. Мне кажется, это не очень-то хорошо и приятно. А легко ли будет новому человеку, пришедшему в ваш проект, влиться в команду и начать приносить пользу? А легко ли будет заменить вас на проекте на время вашего отпуска? Если нет, значит это ваша проблема в первую очередь. Если, конечно, вы собираетесь вообще ходить в отпуск и не собираетесь работать на одном и том же проекте годами (а проекты, бывает, идут и по десятку лет!).

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

Права

C++ на первом курсе это жестоко

После перерыва в 6 лет снова начал писать на C++ (раньше писал на нем больше 10 лет). После C# впечатление шага назад.

Одно не пойму - зачем на 1 курсе давать C++. Язык сложный, очень гибкий...

На C# я могу объяснить, что вывод на консоль это Console.WriteLine. А на C++ мне надо объяснять что такое using namespace, что такое include и т.д. и т.п. И дальше выбор - или идти с cout и объяснять модификаторы, либо с printf, что ничем не проще.

А ввод с консоли это вообще отдельная песня...

Или вот вызывают pow(i, 2). Если i типа int, то компилятор говорит что не может выбрать метод между параметрами double и float. Студенты от этой ошибки просто шалеют. Или pow(i, 1/3) - тут другая радость. Разумеется что 1/3 приводится к целому и ничего не работает. Объясняю что надо писать (float)1/3, чтобы им было понятно что это дробь и компилятору тоже. Мне это понятно, но человеку только пришедшему... хорошо если с pascal в запасе... вот так вот по голове...

Рассказал что if (a=1) это типовая ошибка. Что & и && это разные опреаторы. Разумеется не помогает. Все равно ошибаются.

Точки-с-запятой и скобки

Некоторым студентам так понравилось ставить точки-с-занятой после конца строки, что они подошли к вопросу с излишним фанатизмом.
В результате получаются такие конструкции:

if (a == b);
{
  // выполнится не зависимо от условия
}

Или так:

for (int i=0; i<10; i++);
{
   // выполнится один раз, без цикла
}

Ну и со скобками в блоках конечно тоже беда:

for (int i=0; i<10; i++)
  a++;
  b++;

К сожалению, выравнивания еще мало - надо бы еще скобки блока поставить. Иначе b++ в цикл не войдет.

Особенности сравнения float.NaN

float.NaN - специальное обозначение бесконечности. Но нужно помнить, что две бесконечности не равны по определению. Да и по спецификации тоже.
Т.е.
 float f = float.NaN;
 if (f == float.NaN)
 {
    // никогда не выполнится
 }

Для правильного сравнения используйте float.IsNaN(f).

Быстрое сохранение в XML класса Font, Color, enum...

Вот лень мне было по кусочкам Font сохранять в XML. Нашел вот такой способ:

public static XmlElement AddElementByConverter<T>(XmlElement parentNode, string nodeName, T attrValue)
{
  TypeConverter converter = TypeDescriptor.GetConverter(typeof(T));
  string value = converter.ConvertToString(attrValue));
  .... ну и тут дальше как обычно
}

И загружать просто:

public static T ReadByConverter<T>(XmlNode element, string path, T defaultValue)
{
   T nodeValue = defaultValue;
   XmlNode node = element.SelectSingleNode(path);
   .........
   TypeConverter converter = TypeDescriptor.GetConverter(typeof(T));
   nodeValue = (T) converter.ConvertFromString(valueString);
   if (nodeValue == null)
      nodeValue = defaultValue;
   .........
   return nodeValue;
}

Такая конструкция замечательно глотает и Font и Color и любой enum.
Типа кодюлька номер раз :)

Название

Подумал, если короткие фразы, это "коротюльки", то короткие кусочки кода должны бы называться "кодюльки". Может книгу надо было назвать не Сборник рецептов, а Сборник кодюлек. Ну или как-то так... :)

Интересная штука с загрузкой изображений

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

Сохраняю:

using (MemoryStream ms = new MemoryStream())
{
 this.bitmap.Save(ms, ImageFormat.Bmp); 
 byte[] bitmapData = ms.ToArray(); 
 string imgBase64 = Convert.ToBase64String(bitmapData);
 xmlImage.InnerText = imgBase64;
}

Загружаю:

string imgBase64 = xmlImage.InnerText;
if (!string.IsNullOrEmpty(imgBase64)) 
  byte[] bitmapData = Convert.FromBase64String(imgBase64); 
using (MemoryStream ms = new MemoryStream(bitmapData))   
  this.bitmap = Image.FromStream(ms) as Bitmap;

Все работает без проблем - bitmap отображается как нужно, размеры сохранены
и вообще все отлично.

Но если попытаться сохранить этот загруженный image еще раз,
то получаю ошибку:
        A generic error occurred in GDI+.
Что сие значит не понятно.

Решил проблему просто, но не понятно - либо не закрывать поток,
либо создавать новый image, соответственно с новым потоком.

Т.е. либо так:

  MemoryStream ms = new MemoryStream(bitmapData); 
  this.bitmap = Image.FromStream(ms) as Bitmap;   

Либо так:

  this.bitmap = new Bitmap(Image.FromStream(ms) as Bitmap);

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

UPD: Т.е. получается что при выполнении FromStream используется тот же буфер, что
я создавал в потоке.

UPD: Интересно этот редактор параграфы переставляет. Вроде сохраняешь
нормально, а получается такая каша... Хоть бы пофиксили. Задолбало.