пятница, 26 сентября 2008 г.

Начинающим на заметку. Два поста об оформлении исходного кода.

Фигурные скобки и их влияние на качество кода:

http://blogs.gotdotnet.ru/personal/ezakhareyev/CommentView.aspx?guid=77a8ef9b-19cb-401a-b832-ffac0ad7b3ad


В статье автор дает достаточно логичное обоснование почему фигурные скобки нужно расставлять именно так, как он предлагает :)



Точки выхода или немного о структурном программировании:

http://blogs.gotdotnet.ru/personal/XaocCPS/PermaLink.aspx?guid=72b2322a-6782-4ee6-b4e9-66df9678b56a

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


UPDATE:
Поправил вторую ссылку в которой текст и целевой url не совпадали.

Пожалуй отвечу на коментарии прямо в этот пост.

[mormat] Не знаю, почему в компании DevExpress другие гайдлайны (открывающая скобка на старой" строчке), неужели им удобно читать собственный код.. Сила привычки?

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


[mormat] Что касается множественных return-ов в теле метода, то помоему односторонняя совершенно статья. Где обоснование, где рассмотрение альтернативных точек зрения? Где плюсы, минусы? Я, например, знаю обратную точку зрения, что ряд валидирующих проверок в начале метода (с return-ами) сильно упрощает поддержку кода.

Честно говоря тут я более категорично настроен :) Если речь идет имено о валидации переданных данных, то тут стоит бросать исключения, а не использовать return. Хотя, уверен что ты имел ввиду скорее не валидацию параметров, а проверку на применимость метода.

Как бы там ни было гораздо удобнее поставить точку останова на один-единственный return для того чтобы посмотреть возвращаемое значение.

К тому же если у меня идет некотороая проверка данных и лишняя вложенность уложняет код, то это можно решить следующим образом:

  1. public ResultType DoSomething(SomeType value)  
  2. {  
  3.     // Если параметр невалидный, то этот метод прокинет исключение.  
  4.     ValidateSomeType(value);  
  5.   
  6.     // В некоторых случаях бывает удобно инициализировать объект значением по-умолчанию сразу с его объявлением.  
  7.     ResultType result;  
  8.   
  9.     // Если нам не нужно выполнять никаких действий над объектом, то мы просто выйдем из метода.  
  10.     if (IsAcceptable(value))  
  11.     {  
  12.         ...  
  13.     }  
  14.   
  15.     return result;  
  16. }  

3 комментария:

mormat комментирует...

Помоему обе приведённые тобою ссылки ведут в одно и то же место. Это ошибка, или так и должно быть?

mormat комментирует...

Что касается скобок, каждую из которых следует размещать на новой строке - то я согласен, это лично мне сильно облегчает визуальное восприятие.
Не знаю, почему в компании DevExpress другие гайдлайны (открывающая скобка на "старой" строчке), неужели им удобно читать собственный код.. Сила привычки?

Что касается множественных return-ов в теле метода, то помоему односторонняя совершенно статья. Где обоснование, где рассмотрение альтернативных точек зрения? Где плюсы, минусы? Я, например, знаю обратную точку зрения, что ряд валидирующих проверок в начале метода (с return-ами) сильно упрощает поддержку кода.

mormat комментирует...

Спасибо за ответ.
Честно говоря, в свою очередь, не знаю что и ответить :-) я - со всем согласен. Только прокомментирую, что поставить return в начале метода намного удобнее, чем проверять в дебаггере, какой именно пошёл флоу, чтобы убедиться, что ничего лишнего не выполнилось (но это для длинных методов, которых как известно лучше не писать).