Признаться удивлен, что здесь есть сотрудники SubMain. Попробую на форуме отписать более развернуто, а пока в двух словах:
- ваш документ описывает кроме всего прочего рекомендации и по vb.
- ваш документ более глубокий, по сравнению с вариантом IDesign и больше походит на стандарт, в то время как вариант IDesign - это в большей степени guidline;
- ваш документ лучше в том смысле, что в темах именования предлагает не только то "что надо делать", но и описывает "то что делать не нужно". Справедливости ради надо заметить, что вариант IDesign так же в большом числе описывает то, чего делать не следует, но это все касается больше уже не именования, а стиля программирования в целом;
- у вас гораздо больше примеров, в то время как вариант IDesign более лаконичный;
- у вас есть таблица стандартного именования префиксов для пользовательских элементов, то о чем сейчас идет дискуссия в этом топике;
- субъективно: в целом, ваш документ более глубок, тогда как IDesign более дружелюбен, если так можно выразиться.
Может голосование на Хабре провести, типа кто использует те или иные варианты, если вообще использует?
Не обязательно в контексте .net, это вроде внеязыковый момент.
А вот dmx считает, что cmd. И как тут быть? Завтра появится Вася Пупкин, который захочет вообще писать bSample или ibtnSample. Стоит ли браться за стандартизирование такого скользкого момента, как именование элементов управления через префиксы?
Про смысл: смысл есть, когда кода много, его и читать легче, если он написан в знакомой форме. Учитывая, что с форматированием кода на Хабре не самая лучшая ситуация единый стандарт кода - это неплохая вещь, имхо.
4. Я не стал упоминать порядок декларации переменных, полей, свойств и методов в классах по той причине, что этот момент не сильно влияет читаемость кода. Нужны ли такие избыточные правила в этом стандарте? Не уверен, может кто-то еще выразит свое мнение? Про регионы тоже самое.
1. Если считать со мной - это уже третий голос. Наверное так и сделаем.
2. Я тоже за то, чтобы всегда ставить скобки.
3. Я тоже пользуюсь, но когда начинаешь встречать в чужом коде btnSample вместо cmdSample и многое другое не настолько очевидное, начинаешь задумываться, а так ли это уж и правильно? Такая нотация интересная когда она навязана свержу, типа венгерской, которую знали все, потому-что win32 api написан на ней. Но свой вариант нотации - это уже палка о двух концах: себе удобнее, другим все равно...
Потому-что так же называются аргументы методов этого же класса. Придется использовать this, а это лишнее если добавлять префикс.
int pageIndex;
int GetPageIndex(int pageIndex)
{
}
Из какого города автор? Можно попросить автора обосновать тезис о деиндустриализации страны? Я живу в Свердловской области и не наблюдаю этого явления.
Я тоже так делаю. Это своеобразный вариант венгерской нотации, но теперь, мне кажется, что это не совсем правильно. Совсем не очевидно что такое cmdSample, не лучше ли назвать SampleButton, SampleLinkButton, SampleImageButton? И во всем остальном также:
Ок.
Второй вариант закрытых полей описан в предложении первого источника, приведенного в начале.
Про if: я поступаю точно так же как и ты, но очевидно, что назвать стандартом проще действие через одно условие, чем через три. Вариант который приведен в статье описан во втором источнике. Причин там не описывается, но я думаю, все дело в читаемости и принципе: область видимости всегда в фигурных скобках. В целом с тобой согласен, но, наверное, стоит еще чье-нибудь мнение послушать, чтобы внести изменения.
Иначе как отработать ситуацию, когда меняется ключ? По вашему я должен создать экземпляр предка и присвоить его потомку, вместо того, чтобы просто присвоить простой идентификатор объявленный как Int? Может быть именно тут порылась собака которая у вас обрушала SubmitChanges()?
Где-бы слить standalone patch, а не эти обновления через web?
2. спорно. Нет, конечно, это удобно, но правильно ли?
3. слава богу 2.2 - это только рекомендация :)
lbl Label
llbl LinkLabel
but Button
txt Textbox
mnu MainMenu
chk CheckBox
rdo RadioButton
grp GroupBox
pic PictureBox
grd Grid
lst ListBox
cbo ComboBox
lstv ListView
tre TreeView
tab TabControl
dtm DateTimePicker
mon MonthCalendar
sbr ScrollBar
tmr Timer
spl Splitter
dud DomainUpDown
nud NumericUpDown
trk TrackBar
pro ProgressBar
rtxt RichTextBox
img ImageList
hlp HelpProvider
tip ToolTip
cmnu ContextMenu
tbr ToolBar
frm Form
bar StatusBar
nico NotifyIcon
ofd OpenFileDialog
sfd SaveFileDialog
fd FontDialog
cd ColorDialog
pd PrintDialog
ppd PrintPreviewDialog
ppc PrintPreviewControl
err ErrorProvider
pdoc PrintDocument
psd PageSetupDialog
crv CrystalReportViewer
pd PrintDialog
fsw FileSystemWatcher
log EventLog
dire DirectoryEntry
dirs DirectorySearcher
msq MessageQueue
pco PerformanceCounter
pro Process
ser ServiceController
rpt ReportDocument
ds DataSet
olea OleDbDataAdapter
olec OleDbConnection
oled OleDbCommand
sqla SqlDbDataAdapter
sqlc SqlDbConnection
sqld SqlDbCommand
dvw DataView
- ваш документ описывает кроме всего прочего рекомендации и по vb.
- ваш документ более глубокий, по сравнению с вариантом IDesign и больше походит на стандарт, в то время как вариант IDesign - это в большей степени guidline;
- ваш документ лучше в том смысле, что в темах именования предлагает не только то "что надо делать", но и описывает "то что делать не нужно". Справедливости ради надо заметить, что вариант IDesign так же в большом числе описывает то, чего делать не следует, но это все касается больше уже не именования, а стиля программирования в целом;
- у вас гораздо больше примеров, в то время как вариант IDesign более лаконичный;
- у вас есть таблица стандартного именования префиксов для пользовательских элементов, то о чем сейчас идет дискуссия в этом топике;
- субъективно: в целом, ваш документ более глубок, тогда как IDesign более дружелюбен, если так можно выразиться.
Не обязательно в контексте .net, это вроде внеязыковый момент.
2All: кто-нибудь против?
2. Я тоже за то, чтобы всегда ставить скобки.
3. Я тоже пользуюсь, но когда начинаешь встречать в чужом коде btnSample вместо cmdSample и многое другое не настолько очевидное, начинаешь задумываться, а так ли это уж и правильно? Такая нотация интересная когда она навязана свержу, типа венгерской, которую знали все, потому-что win32 api написан на ней. Но свой вариант нотации - это уже палка о двух концах: себе удобнее, другим все равно...
int pageIndex;
int GetPageIndex(int pageIndex)
{
}
SampleTextbox,
SampleLabel,
SampleLiteral,
SampleList,
SampleObjectDataSource,
SampleHyperlink,
SampleImage
на самом деле, проигрыш в длине переменной небольшой, но наглядности больше. Как думаешь?
Второй вариант закрытых полей описан в предложении первого источника, приведенного в начале.
Про if: я поступаю точно так же как и ты, но очевидно, что назвать стандартом проще действие через одно условие, чем через три. Вариант который приведен в статье описан во втором источнике. Причин там не описывается, но я думаю, все дело в читаемости и принципе: область видимости всегда в фигурных скобках. В целом с тобой согласен, но, наверное, стоит еще чье-нибудь мнение послушать, чтобы внести изменения.