Вы называете средства управления на формах с помощью той же конвенции в качестве частной переменной?
Если вы хотите сворачивать свои собственные, а не использовать стороннюю сторону, есть также решение для JavaScript:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<script>
function getMobileOperatingSystem() {
var userAgent = navigator.userAgent || navigator.vendor || window.opera;
// Windows Phone must come first because its UA also contains "Android"
if (/windows phone/i.test(userAgent)) {
return "Windows Phone";
}
if (/android/i.test(userAgent)) {
return "Android";
}
// iOS detection from: http://stackoverflow.com/a/9039885/177710
if (/iPad|iPhone|iPod/.test(userAgent) && !window.MSStream) {
return "iOS";
}
return "unknown";
}</script>
<script>
function DetectAndServe(){
if (getMobileOperatingSystem() == "Android") {
window.location.href = "http://www.Androidexample.com";
}
if (getMobileOperatingSystem() == "iOS") {
window.location.href = "http://www.IOSexample.com";
}
if (getMobileOperatingSystem() == "Windows Phone") {
window.location.href = "http://www.WindowsPhoneexample.com";
}
if (getMobileOperatingSystem() == "unknown") {
window.location.href = "http://www.NowherLandexample.com";}
};
</script>
</head>
<body onload="DetectAndServe()">
</body>
</html>
11 ответов
Это могло бы быть парадоксально для некоторых, но мы используем страшную Венгерскую запись для элементов UI.
Логика проста: поскольку любые определенные данные возражают, что у Вас может быть два или больше средств управления, связанные с ними. Например, Вы имеете контроль, который указывает на дату рождения на текстовом поле, Вы будете иметь:
- текстовое поле
- маркировка, указывающая, что текстовое поле для дат рождения
- календарное управление, которое позволит Вам выбирать дату
Для этого у меня был бы lblBirthDate для маркировки, txtBirthDate для текстового поля и calBirthDate для календарного управления.
Я интересуюсь слушанием, как другие делают это, как бы то ни было.:)
Венгерская запись или нет, мне более любопытно, если люди предварительно ожидают m_ или _ или независимо от того, что они используют для стандартных переменных члена парламента, не занимающего официального поста.
Для меня большая победа с соглашением о присвоении имен предварительного ожидания подчеркивания членам парламента, не занимающим официального поста имеет отношение к Intellisense. Так как подчеркивание предшествует любой букве в алфавите, когда я делаю ctrl-space для перевода в рабочее состояние Intellisense, существуют все мои _privateMembers, право наверху.
Средства управления, тем не менее, являются другой историей, насколько именование идет. Я думаю, что объем принят, и предварительно ожидающий несколько букв, чтобы указать, что тип (txtMyGroovyTextbox, например) имеет больше смысла по той же причине; средства управления сгруппированы в Intellisense типом.
Но на работе, это - VB полностью, и мы делаем mPrivateMember. Я думаю, что m мог бы обозначать модуль.
Я лично префикс частные объекты с _
Средства управления формой всегда снабжаются префиксом тип, единственная причина, которую я делаю, это из-за intellisense. С большими формами становится легче "получить значение маркировок", просто введя lbl, и выбор его из списка ^_^ Он также следует за логикой, указанной Jon Limjap.
Хотя это действительно идет снова Microsofts Инструкции по Кодированию.NET, проверьте их здесь.
Я проник через VB и держал на префикс типа управления для средств управления. Мои члены парламента, не занимающие официального поста используют нижний Camel-регистр (firstLetterLowercase), в то время как общедоступные участники используют случай Pascal/upper-camel (FirstLetterUppercase).
Если существует слишком много идентификаторов/участников/местных жителей, чтобы иметь 90%-й шанс запоминания/предположения, чем это называют, больше абстракции, вероятно, необходимо.
Я никогда не убеждался, что префикс типа хранения полезен и/или необходим. Я действительно, однако, делаю сильную привычку к следующим стилем любого кода, который я использую.
Венгерская запись или нет, мне более любопытно, если люди предварительно ожидают m_ или _ или независимо от того, что они используют для стандартных переменных члена парламента, не занимающего официального поста.
Luke,
Я использую _ префикс для моих объектов библиотеки классов. Я использую Венгерскую запись исключительно для UI по причине, которую я заявил.
Я не делаю, но я ценю Вашу логику. Я предполагаю причину, которую не делает большинство людей то, что символы нижнего подчеркивания выглядели бы довольно ужасными в Окне свойств во время проектирования. Это также подняло бы дополнительный символ горизонтального пространства, которое находится в большом почете в прикрепленном окне как этот.
Я никогда не использую символы нижнего подчеркивания в своих именах переменной. Я нашел, что что-либо помимо альфы (иногда алфавитно-цифровой) символы чрезмерно, если не потребовано языком.
Я записываю название столбца базы данных, который они представляют.
Я нахожусь в Прописном/Строчном лагере ("заголовок" является частным, "Заголовок" общедоступен), смешанный с "венгерской" нотацией для Компонентов UI (tbTextbox, lblLabel и т.д.), и я рад, что у нас нет Визуальных Нечувствительных к регистру основных разработчиков в команде :-)
Мне не нравится подчеркивание, потому что это выглядит довольно ужасным, но я должен признать, что это имеет преимущество (или недостаток, в зависимости от Вашей точки): В отладчике все частные переменные будут на вершине из-за _ являющийся сверху алфавита. Но с другой стороны, я предпочитаю, чтобы моя частная/общедоступная пара была вместе, потому что это допускает более легкую отладку логики метода считывания/метода set, поскольку Вы видите частную и общественную собственность друг рядом с другом,
Я использую m_ для членских переменных, но я все больше становлюсь соблазненным только к использованию lowerCamelCase как, я делаю для параметров метода и локальных переменных. Общедоступный материал находится в UpperCamelCase.
Это, кажется, более или менее принятая конвенция через сообщество.NET.