На сайте ведутся работы Стандартизация процесса разработки программного обспечения | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Нематериальное стимулирование, компенсационные пакеты » Что мешает программистам IT-отделов…

Стандартизация процесса разработки программного обспечения

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2002-11-29 20:49:55
NKudinov » Всем
Ответьте пожалуйста на вопрос зачем нужна ( и нужна ли вообще) стандартизация кодирования программного обеспечения( составления стандартов на формирования наименований и т.д) и на скоко это окупаеться.
[Показать все ответы на это сообщение]
2002-11-30 09:48:41
GMN » NKudinov

Не знаю как кому, а мне вопрос не понятен. Теряюсь в догадках о чем речь: о компиляторах (кодирование...), о стандартизации интерфейсов или о объединённых общим стандартом названиях как части маркетинга для этих программ?

[Нет ответов на это сообщение]
2002-12-01 15:39:16
NKudinov » Всем
Да, раскрыл я вопрос не полно. Постараюсь исправиться.

Имелл ввиду именно кодирование т.е написание исходного кода программного обеспечения ( то, чем занимаються программисты)

Вот небольшой пример правил кодирования на языке C++

1. Использование регистра символов
1.1. Имена должны начинаться с заглавной буквы. Если имя составлено из нескольких слов, то каждое из них должно начинаться с заглавной буквы. Это общее правило для для любых имен, используемых в программе.
2. Оформление и структура программы.
2.1. Отступ вправо составляет 4 символа для нового оператора программы.
2.2. Одна строчка - один оператор. Есть исключения, описанные ниже.
2.3. Разделители ставятся непосредственно после имени или закрывающей скобки, а перед следующим именем необходим пробел. Это касается всех разделителей, за исключением математических операций, правила для которых будут оговорены отдельно. После закрывающей скобки ; ставится только в декларациях.
2.4. Крайне не рекомендуется использовать глобальные переменные. Следует использовать Singleton.
2.5. Крайне не рекомендуется использовать директиву #include внутри заголовочных файлов. Следует использовать forward declarations и создавать основной передкомпилируемый заголовок с часто используемыми типами.
2.6. Запрещается гасить warnings прагмами, кроме случаев, когда это невозможно сделать другими способами, а Вы точно знаете, что делаете.
2.7. Не использовать конструкции вида
pBM->GetClass(i)->GetProperty(i)->GetName();
Можно схватить AV.
3. Конструкции языка должны подчиняться следующим правилам:
3.1. Определение классов.
class CseMyClass : public CseMyParentClass
{
private:
// private attributes and operations
protected:
// protected attributes and operations
public:
// public constructors
virtual ~CseMyClass();
// public attributes and operations

friend class CseFirstFriendClass;
friend class CseSecondFriendClass;
};
Всегда следует делать деструктор виртуальным. Исключения могут составить только те случаи, когда наличие именно виртуального деструктора нарушает логику уничтожения объектов.

Имя класса должно начинаться с буквы C.

Между начальной буквой C и содержательной частью имени класса допустима аббревиатура продукта, записанная маленькими буквами. В данном примере эта аббревиатура se.
3.2. Определение структур.
Структуры определяются аналогично классам.
3.3. Определение перечисляемых типов.
typedef enum
{
ptUnknown = 0,
ptWideString,
ptInt4
} EsePropertyType;

Имя каждого элемента должно начинаться с префикса, составленного из начальных букв слов, составляющих имя типа.
Следует явно указывать значение первого элемента перечисления.
Имя перечисления должно начинаться с большой буквы E и может содержать аббревиатуру продукта.
3.4. Определение переменных.
bool bLazyRead;
CseString sClassName;
unsigned i, n;
int nPropertiesCount = 0;
char *pFirstString, *pSecondString;
CseList lStringList;
CseList *plClassesList;
CseClassInfo *pCI;

Допускается указание нескольких переменных в одном определении, а также инициализация в определении. Однако не следует этим злоупотреблять - код должен оставаться легко читаемым.
3.5. Определение констант
Аналогично определению переменных.
3.6. Обработка исключений
try
{
if (/*some_condition*/)
throw /*some_exception*/;
}
catch (EXType1 &ex)
{
}
catch (EXType2 &ex)
{
}
catch (:)
{
}

3.7. Условный оператор
if (/*some_condition*/)
{
// code
}
else
{
// code
}

if (/*some_condition*/)
/*simple_operator*/;

На равенство нулю приверяем так: if (!some_variable)
На неравенство нулю приверяем так: if (some_variable)
При сравнении на равенство, во избежание ошибки имеет смысл помещать константу слева от опрератора сравнения:
if (3 == some_variable)


Вот мне не понятно зачем тратить время на выработку таких соглашений. И принесут ли они реальную пользу для проекта. т.е сократиться ли время разработки, улучшиться ли качество программы от этого.
[Показать все ответы на это сообщение]
2002-12-02 00:25:46
Кирилл Лебедев » NKudinov
Данная стандартизация позволяет:
1. Другим программистам легко разбираться в коде, если их коллега, писавший код, уволился, заболел или временно отсутствует.
2. Самому программисту, писавшему код. Со временем код забывается. А так - легко вспомнить.
3. Избавиться от решения мелких проблем, возникающих в процессе написания кода (как назвать класс, как назвать переменную, куда ее поместить и т.п.).

Есть и другие преимущества, о которых в один момент и не вспомнить.
[Нет ответов на это сообщение]
2002-12-03 22:45:14
Serega » NKudinov

>>Вот мне не понятно зачем тратить время на выработку
> таких соглашений.

Время тратится один раз, стандарт позволяет привести в однообразный вид весь код проекта

>И принесут ли они реальную пользу для
> проекта. т.е сократиться ли время разработки,

врядли, а вот время на исправление ошибок сократится в разы.

>улучшиться ли качество программы от этого.

главное, что не ухудшится :-)

[Нет ответов на это сообщение]


Яндекс.Метрика