A>Это очень просто — стиль кодирования всегда берется из Framework который юзаешь — используешь Java — Camel Notation, используешь A>MFC — венгерская.
A>Связано с тем что ты все равно в коде используешь Framework и если у тебя будет другая нотация то это значит что у тебя их будет A>две. Т.е. никакой.

Ага. Используешь ATL + boost + STL и идешь вешаться, потому что в ATL верблюд, в бусте и стле — foo_bar.

А>>1) обязательное документирование нового кода, и постепенное документирование старого

A>Документировать код достаточно бесполезно. Документировать нужно дизайн. Код в случае непонятки в конкретном месте проще переписать чем по доке с ним разбираться. Ну т.е. нужно документировать не как код рботает а что он делает,
О да. А лучше иметь юнит/ацкептанс/регрешн тесты на этот код.

A>поэтому описание 2 пол экрана на класс как правило полезней чем описание по 2 строчки на каждую процедуру в нем.
Yep.


A>Правда от документирования кода есть вот какая польза. Нужно ввести правило, что если что делает процедура не ясно из ее названия то нужно это писать в комментарии. Что приводит очень быстро к вменяемым названиями во всем проекте потом учто случаев когда нельзя по человечески процедуру назвать почти не бывает.

А>>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их

A>Учти что архитектура это не просто паттерны.

А>>3) периодически проверять как сотрудники применяют pattern-ы
Да-да. За регулярное применение паттернов премировать, за недовыполнение
плана по паттернам — штрафовать.

A>Это Code Review называется.