Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза.
Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Re: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Ничего не изменилось. Никто никогда не рекомендовал именовать приватные методы с маленькой буквы. С маленькой буквы именуются только локальные функции в Немерле.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза.
А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
Первый раз слышу про приватные методы с маленькой буквы
Re: Приватные методы с маленькой, публичные с большой
Здравствуйте, Аноним, Вы писали:
А>Сейчас почему то мода пошла и приватные и публичные писать с большой. Но ведь это не удобно -- по названию метода должно быть стразу понятно публичный он или приватный. Разница огромная. Как минимум, в приватных нет проверки аргументов на null, а в публичных есть. Публичность/приватность должна бросаться в глаза.
А>Если мне память не изменяет, раньше рекомендовали приватные писать с маленькой буквы. А теперь что изменилось?
У нас такое используется.
Но мне больше не нравится чем нравится.
Сегодня метод приватный, а завтра его делаем публичным и везде меняй регистр.
А вот "protected" это приватный или публичный ? Аналогично с internal.
Как тут поступать ?
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, _NN_, Вы писали: _NN>>А вот "protected" это приватный или публичный ? Аналогично с internal.
QL>К публичным относятся public, protected и protected internal.
Ну вот, а некоторые считают, что protected относится как раз к приватным.
Тут как бы вопрос что есть публичное, что приватное.
Если смотреть относительно класса, то public и internal.
А если смотреть относительно сборки, то тогда ваш вариант.
QL>К приватным — private и internal.
Здравствуйте, _NN_, Вы писали: _NN>Ну вот, а некоторые считают, что protected относится как раз к приватным.
Они ошибаются =)
Приватные — видимые только внутри контейнера (класса/сборки) — private/internal. Все остальные — публичные.
Re[2]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _NN_, Вы писали:
_NN>Сегодня метод приватный, а завтра его делаем публичным и везде меняй регистр.
Не только менять регистр, но и добавлять проверку входных параметров. Вообще это серьезное изменение архитектуры, так что буква далеко не самый главный момент в этом случае. Буква меняется одним нажатием кнопки, а вот остальное не так просто.
_NN>А вот "protected" это приватный или публичный ? Аналогично с internal. _NN>Как тут поступать ?
Критерий очень простой: там, где вы проверяете аргументы метода на null -- пишем с большой буквы, где нет -- с маленькой. То есть там, где маленькая буква, передаются 100% валидные аргументы (потому что вызываем его только мы для внутренних нужд и никто другой туда каку передать не сможет).
То есть protected с большой, т.к. могут передать неверные аргументы из стороннего кода. Internal -- я тоже пишу с большой, т.к. сам случайно могу передать туда не то что нужно (всего в голове не удержишь).
Итого, с маленькой только чистый private.
Re[4]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _NN_, Вы писали:
QL>>К публичным относятся public, protected и protected internal.
_NN>Ну вот, а некоторые считают, что protected относится как раз к приватным. _NN>Тут как бы вопрос что есть публичное, что приватное.
В protected могут передать неверные аргументы, по этому производим их проверку. А следовательно, и писать нужно с большой буквы.
_NN>Если смотреть относительно класса, то public и internal. _NN>А если смотреть относительно сборки, то тогда ваш вариант.
Нужно смотреть относительно необходимости проверки аргументов на null.
Re[5]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _NN_, Вы писали:
_NN>Мое личное мнение, всегда писать с большой буквы и не париться
А приватные поля, локальные переменные, аргументы методов вы тоже с большой пишите? Почему же с этим паритесь??? Пишите как в Delphi -- все с большой буквы.
Почему приватные поля пишите с маленькой, а приватные методы с большой? Где критерий?
Re[7]: Приватные методы с маленькой, публичные с большой
Приватные вообще не обязаны регламентироваться стандартом, т.к. это не влияет на использование библиотеки.
_R_>Да-же проще, чем не выплатить заработанное.
Не понятно с какой целью вы здесь это пишите? Во-первых, вопросы оплаты я не решаю. Во-вторых, не всегда заказчик не прав. Работнички ведь тоже разные бывают. Могу сказать, что кроме вас проблемы по оплате ни с кем более не возникали.
Re[3]: Приватные методы с маленькой, публичные с большой
По-моему эта мода пошла от исходников Microsort
Если Reflector'ом посмотреть их исходники, там все методы и приватные и публичные с заглавной буквы.
Зато там встречаются пары методов: публичный X и приватный XInternal.
Я придерживаюсь правила: приватные методы с маленькой буквы. У бывают пары: публичный X и приватный x. MS'подход мне не нравится, так как увеличивает длину названия метода.
Здравствуйте, IObserver, Вы писали:
IO>В табличке написано:
IO>Property IO>Pascal IO>BackColor
IO>без всяких уточнений (приватные или публичные).
А кто сказал, что уточнения должны быть. Ясно же сказано, что метод — с заглавной буквы.
IO>Приватные вообще не обязаны регламентироваться стандартом,
Обязаны.
IO>т.к. это не влияет на использование библиотеки.
При чем тут библиотеки? Это соглашения по написанию кода, но принимаются они для легкого чтения. Вот вы привыкли читать с маленькой буквы и ввели свой code style — но эта привычка далека от си шарпа. Более того — она вредна. Упрощая себе code review вы усложняете жизнь пишущим в правильном стиле, заставляя задумываться о том как пишешь, а не что пишешь и какой ... ввел это в корпоративный стандарт.
И доводы типа
В protected могут передать неверные аргументы, по этому производим их проверку. А следовательно, и писать нужно с большой буквы.
и
Нужно смотреть относительно необходимости проверки аргументов на null.
не могут служить оправданием для отступа от общепринятых соглашений code style-а. Нет таких позиций относительно шарпа. Тут нет венгерской нотации и нет методов со строчной буквы. Плохо это или хорошо, нравиться тебе или нет, но это общепринятое соглашение. Есть code style — его нужно соблюдать. Точка. Только вот он должен быть не придуман кем-то в команде и не натаскан кусками из других языков программирования. Даже если 100% команды привыкли к стилю иного языка. Завтра придет новый разработчик и время на чтение существующего кода будет значительно выше, по сравнению с кодом написанным по правилам.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 32>>
Re[4]: Приватные методы с маленькой, публичные с большой
Здравствуйте, igor-booch, Вы писали:
IB>По-моему эта мода пошла от исходников Microsort IB>Если Reflector'ом посмотреть их исходники, там все методы и приватные и публичные с заглавной буквы.
Эта мода пошла за долго до рефлектора и .net. В плюсах для приватных методов точно такое соглашение.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Приватные методы с маленькой, публичные с большой
Здравствуйте, _Raz_, Вы писали:
_R_>При чем тут библиотеки? Это соглашения по написанию кода, но принимаются они для легкого чтения. Вот вы привыкли читать с маленькой буквы и ввели свой code style — но эта привычка далека от си шарпа. Более того — она вредна. Упрощая себе code review вы усложняете жизнь пишущим в правильном стиле, заставляя задумываться о том как пишешь, а не что пишешь и какой ... ввел это в корпоративный стандарт.
Корпоративный стандарт, батенька, может быть глупой выдумкой. А может быть и постарше нас с Вами, и тогда отступление от общепринятого может иметь очень давние корни десятилетий и высокую цену отказа от. Поэтому постепенно лично я пришел к правилу, что садясь за новый проект или инструмент, лучше не лезть туда со своим уставом, а переконфигурировать собственный мозг. А то до смешного доходит, когда народ даже раскладку клавиатуры под себя лепит, не говоря уже про набор шорткатов в IDE. Типа, так привык, и по-другому уже не умею.
Лёгкость вообще — понятие субъективное, равно как и "правильность". Иначе ведь можно было бы закрепить один "правильный лёгкий" способ на уровне синтаксиса языка и не париться.
Помнится, первый раз попробовал написать в студенчестве прогу на Сях (после освоения Паскаля). Написал код красиво, чтобы читать было "легко и правильно", все идентификаторы сделал с заглавной буквы... В том числе и функцию main() назвал Main() — а оно не компилит...
Re[3]: Приватные методы с маленькой, публичные с большой
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, _NN_, Вы писали: _NN>>А вот "protected" это приватный или публичный ? Аналогично с internal.
QL>К публичным относятся public, protected и protected internal. QL>К приватным — private и internal.
Если уж делить область видимость членов на две категории, то не на (1) открытые и (2) закрытые, а тогда уж на (1) закрытые и (2) exposable. Т.е. все, что не приватное, то exposable, т.е. доступно кому-то вне этого класса. При этом у этого множества "досутпных не только мне" членов есть подмножества: открытые методы, закрытые, внутренние. В том же Eiffel-е класс может экспоузить свои члены конкретным классам, это не делает эти члены публичными.
Но в любом случае, различные идиомы именования методов в зависимости от области видимости — не приняты. Вот поля — другое дело. Сокласно Framework Design Guidelines открытые поля в PascalCase-е, а вот закрытые поля — в camelCase-е с возможность использования лидирующего подчеркивания.
Если нам не помогут, то мы тоже никого не пощадим.
Пишите как в Delphi -- все с большой буквы.
