Permalink
Browse files

v1

  • Loading branch information...
1 parent 43ff6df commit c4d8f448b6ec2918b7f834bbc51f0a4c4fe303e3 @gaech committed May 24, 2012
Showing with 164 additions and 2 deletions.
  1. +22 −2 README.md
  2. +142 −0 Style.cs
View
@@ -72,12 +72,32 @@
* Используйте стиль Кэмел.
* Из имени и типа параметра должны быть понятны его назначение и смысл.
+### Локальные переменные
+* Используйте стиль Кэмел.
+* Объявляйте переменные непосредственно перед их использованием.
+
## Стиль кода
### Оформление
* Используйте **табуляцию**, а не пробелы для отступов.
+* Избегайте строк длиннее 110 символов, переносите инструкцию на другую строку при необходимости.
+* При переносе части кода инструкций и описаний на другую строку вторая и последующая строки должны быть отбиты вправо на один отступ (табуляцию).
+
+### Комментарии
+* Отделяйте текст комментария одним пробелом «// Текст комментария.»
+* Комментируя код, старайтесь объяснять, что он делает, а не какая операция производится.
+
+## Общие советы
+* Не используйте литеральные константы (магические числа, зашитые в код размеры буферов, времена ожидания и тому подобное). Лучше определите константу (если вы никогда не будете ее менять) или переменную только для чтения (если она может измениться в будущих версиях вашего класса).
+* Старайтесь обрабатывать только известные вам исключения! Если целью перехвата исключений является очистка ресурсов после сбоя, лучше воспользоваться секцией finally.
+
+## Организация проектов
+### Именование
+* Для названия проекта используйте имя продукта, затем название подсистемы. Например, ProjectName.Logic (корневой неймспейс будет Touchin.ProjectName.Logic)
+* Название всех внутренних проектов должно начинатся с Touchin, чтобы их было легко отличить от проектов заказчиков. Например, Touchin.Framework
-## Организация проекта
### Типы
-Все не вложенные типы (размещаемые в пространствах имен или непосредственно в глобальном пространстве), за исключением делегатов, должны находиться в отдельных файлах.
+Все не вложенные типы (размещаемые в пространствах имен или непосредственно в глобальном пространстве), за исключением делегатов, должны находиться в отдельных файлах.
+
+
View
142 Style.cs
@@ -0,0 +1,142 @@
+using System;
+using System.Collections;
+
+using Touchin.Core;
+using Touchin.ProjectName.Repositories;
+
+namespace Touchin.ProjectName.Service
+{
+
+ public enum SettingsType
+ {
+ InMemory, // default settings mode
PVoLan
PVoLan May 24, 2012 Collaborator

//Используйте табуляцию, а не пробелы для отступов.
По-моему, здесь используются таки пробелы...

Вообще, давно не встречался с проблемой табов-пробелов, у всех как-то обычно 4 пробела на таб выставлено, так что, имхо, это неактуально.

+ InFile
+ }
+
+ public interface ISettingsProvider
+ {
+ void SetValue (string key, string value);
+ string GetValue (string key);
+ }
+
+
+ public class SettingsProvider : ISettingsProvider
+ {
+ // Fields
+
globchastyy
globchastyy May 24, 2012 Collaborator

Еще мне не нравятся комментарии типа // Fields // Constructors и тп

abaskov
abaskov May 24, 2012

О! Вместо них я бы предложил использовать #region. Например 4тыря монотач конструктора удобно в них прятать и забывать про них.

globchastyy
globchastyy May 24, 2012 Collaborator

А мне region совсем не нравятся, так как в конце концов туда часто попадают ненужные вещи (методы не относящиеся к этому region).

abaskov
abaskov May 24, 2012

А зачем туда их засовывать? :)

gaech
gaech May 24, 2012 Owner

Сейчас монодевелоп уже не генерирует 4 конструктора :) Для упрощения навигации по классу можно "свернуть" все методы(Edit - Folding), тогда видны только сигнатуры методов. Это очень удобно. Регионы были нужны, когда не было partial классов и все прятать надо было в самом классе.

abaskov
abaskov May 24, 2012

Ок, убедил, согласен.

+ public const string SettingsFilePath = "Константа";
PVoLan
PVoLan May 24, 2012 Collaborator

Настаиваю на том, чтобы константы были большими буквами!

public const string SETTINGS_FILE_PATH;

abaskov
abaskov May 24, 2012

С++ и C попахивает :) Тогда они будут слишком сильно выделяться из общего кода, а мне не понятном зачем константы выделять.
В данном случае предлагаю за рефернс брать дизайн .Net фреймворка, там все константы обычным Camel'ом сделаны.

+
+ SettingsType _settingsType;
+ protected int _itemsCount = 10;
globchastyy
globchastyy May 24, 2012 Collaborator

нижнее подчеркивание не нравится только мне?

abaskov
abaskov May 24, 2012

Я за маленькую букву у private, а у protected и public Большая. _ имхо из javascript'a пришел, где прайватов вообще нет.

+
+
+
+ // Constructors
+ public SettingsProvider () : this (SettingsType.InMemory)
+ {}
+
+ public SettingsProvider (SettingsType settingsType)
globchastyy
globchastyy May 24, 2012 Collaborator

Мне не очень понятны пробелы после названия методов перед скобками

gaech
gaech May 24, 2012 Owner

Мне показалось, что так аккуратней код выглядит.

+ {
+ _settingsType = settingsType;
+ MaxValue = 100;
+ }
+
+
+
+ // Events
+
+ public event Action<string,string> ValueChanged;
+
+
+
+ // Properties
+
+ public SettingsType SettingsType
+ {
+ get
+ {
+ return _settingsType;
+ }
+ }
+
+ public int MaxValue
+ {
+ get;
+ protected set;
+ }
+
+
+
+ // Methods
+
+
+ public void SetValue (string key, string value)
+ {
+ // Пример комментария к блоку кода
+ // Дальше будет выполнена проверка параметров,
+ // чтобы избежать выполнения метода с
+ // неверными агрументами
+
+ if (string.IsNullOrEmpty(key)) throw new ArgumentNullException ("key");
+
+ if (string.IsNullOrEmpty(value))
+ throw new ArgumentNullException ("value");
PVoLan
PVoLan May 24, 2012 Collaborator

Noooooooooooooooooooooo!!!

Либо в одну строчку, либо скобочки

gaech
gaech May 24, 2012 Owner

Что не так?

abaskov
abaskov May 24, 2012

Одна строчка без скобок имхо ок, поддерживаю такой вариант.

PVoLan
PVoLan May 24, 2012 Collaborator

Да, только в этой строчке это правило нарушено

+
+ // Пример кода к конкретной строке
+ var invariantKey = key;
+
+ switch (_settingsType) // еще один вариант
+ {
+ case SettingsType.InMemory: invariantKey = key.ToLower(); break;
+ case SettingsType.InFile:
+ invariantKey = string.Format("{0}/{1}",SettingsFilePath,key);
+ break;
+ }
+
+ // TODO: сохранить значение по ключу
+
+ OnValueChanged(key, value);
+
+ }
+
PVoLan
PVoLan May 24, 2012 Collaborator

Настаиваю на минимум трех пустых строчках между методами

gaech
gaech May 24, 2012 Owner

Без аргументов не понятно зачем так делать.

PVoLan
PVoLan May 24, 2012 Collaborator

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

globchastyy
globchastyy May 24, 2012 Collaborator

одна пустая строчка на мой взляд ок, между разными методами private, protected, public можно поставить две

gaech
gaech May 24, 2012 Owner

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

abaskov
abaskov May 24, 2012

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

PVoLan
PVoLan May 24, 2012 Collaborator

Одна пустая строка часто используется внутри метода. Даже две пустые строки могут использоваться внутри метода. Три пустых строки внутри метода - странно, поэтому можно их использовать для разделения методов.

Когда "дырка" внутри метода больше, чем "дырка" между методами, это выглядит неудобно.

+ public string GetValue (string key)
+ {
+
+ while (true)
+ {
+ // correct killer loop
+ }
+
+ for (int i = 0; i < key.Length; i++)
+ {
+
+ }
+
+ try
+ {
+
+ }
+ catch
+ {
+ // TODO: log exception
+ throw ex; // если не знаешь, как обработать исключение, то его лучше отпустить :)
+ }
+
+ using (disposable1)
+ using (disposable2)
+ {
+
+ }
+ }
+
+ protected virtual void OnValueChanged (string key, string value)
+ {
+ var handler = ValueChanged;
+
+ if(handler != null)
globchastyy
globchastyy May 24, 2012 Collaborator

после if здесь следует поставить пробел

PVoLan
PVoLan May 24, 2012 Collaborator

Зачем? о_О?

globchastyy
globchastyy May 24, 2012 Collaborator

так как после while, for, switch есть пробелы

PVoLan
PVoLan May 24, 2012 Collaborator

После while, for, switch пробел, имхо, тоже нафиг не нужен. Также как при объявлении/вызове метода

abaskov
abaskov May 24, 2012

Я за пробел. В противном случае if(), while() читается как вызов метода.

PVoLan
PVoLan May 24, 2012 Collaborator

о_О. Никогда такой ассоциации не возникало. У вас if синеньким не подсвечивается?

abaskov
abaskov May 24, 2012

Здесь скорее необходимо просто общее следование концепции. Ключевые слова от скобок отделяются. А к методам скобки прикрепляются.

Ты же нигде не видишь lock() или bool() или public(). А if и прочее это ключевые слова.

PVoLan
PVoLan May 24, 2012 Collaborator

lock() - вижу.

хотя в любом случае имхо, в этом пробеле всем пофик

+ {
+ handler (key, value);
+ }
+ }
+ }
+}

6 comments on commit c4d8f44

Collaborator

Нет примера с приватным методом. Мне больше нравится не опускать слово private, так код выглядит ровнее

Collaborator

еще тут в некоторых местах в вызове метода перед скобками есть пробелы, а в некоторых нет, я за то чтобы их не было

Мои пожелания:
private опускать, и так ясно что если его нет, то метод private. Еще Мигель на всех за это ругался.
Пробел после метода и перед скобками () мне тоже не понятен, я за method();

Еще из мыслей:
Не совсем кодинг стайл, но тоже важно. Отказаться от параметризованных Aciton и Func. Вместо них использовать обычное описание делегатов. Проблема в том что когда из стороннего кода подписываешься не понятно что означают аргументы в каком-нить Action скобка int, int, int скобка.

UPD парсер скобочки съел!

Collaborator

private должен жить! Отсутствие private вносит неопределенность в код!

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

Код должен быть максимально языконезависимым!

Ээээ, как может быть код языконезависимым если он на C# написан? Тогда можно от евентов отказаться, в Java то их тоже нет.

В java по дефолту package-private что можно считать тем же прайватом -http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
К сожалению большая часть пишет на C# и только на нем, поэтому каждый раз ставить private не вижу смысла - код получается избыточным. C++ структуры да и вообще структуры мы никогда не пишем, поэтому про них не надо думать.

Please sign in to comment.