- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
<?php
class Train {
private $strFrom;
private $strTo;
private $strName;
....................................
public function __construct($arrParameters) {
$objThis = $this;
$objThis->strFrom = $arrParameters['strFrom'];
$objThis->strTo = $arrParameters['strTo'];
$objThis->strName = $arrParameters['strName'];
................................
$intCount = count($arrParameters);
for ($intI = 0; $intI < $intCount; $intI++) {
............................
}
................................
foreach ($arrParameters as $strKey => $mixedValue) {
............................
}
}
....................................
}
И кстати да, если область использования переменнной по высоте меньше одного экрана - это ставит под сомение её использование, но не факт, что цикл со временем не увеличится, так что - спорно
так что если код по каким-либо причинам будет эдитися в простом редакторе - то это безусловно крайне полезно, ну или автор олдфаг и привык так.
Главное - что у него есть свой стайл. По сравнению с другими творениями этого раздела - это просто конфета, а не код
$objThis = $this;
обернутся рано или поздно трудноотлаживаемым пиздецом
но это уже вопрос соблюдения принятого стиля
Как тут без венгерки?
Это и есть "wrong code looks wrong"
Во всех остальных случаях (кроме таких языков ;)) -- плохо.
За объяснением смотреть весьма спорную, и местами откровенно лажевую, но все таки очень познавательную и интересную статью Спольски "let the wrong code look wrong".
Смысл в том, что Вы можете случайно написать:
Только я считаю что префикс "obj" не нужен (по умолчанию можно считать объектом) и почему в конструкторе по хешу бродят без коснтант?
да ну? для хешей (карт) индекс то же что и ключ, и он вполне может быть целочисленным, но не 0..n
h - hash
a - array (тот же хеш только ключи 0..n)
o - object
можно даже вроде
lbl - обьект типа Label
Тоесть $a['1'] есть, и $a[22] есть, а $[2] нету?
Это крайне нездоровая ситуация, imho)
Просто в PHP хеши и массивы выглядят одинаково, и это может привести к путанице (кстати, это одна из причин, почему php causes brain damage (c) -- люди и код начинают путать хеши и массивы): даже в перле они выглядят по разному.
Что бы скомпенсировать эту ляпу языка и гоже юзать разные префиксы.
в таких случаях даже венгерская нотация не спасет
>>беспорядочный массив с черт знает какими индексами. Меня
>>помнится долго клинило, в массиве $a=array('a','b') $a[1]='c'
>>сделает нам массив из трех элементов или перезапишет второй?
О_о ... пхп такой пхп
что выведет print_r такого массива?
входящие аргументы функции ты тоже по венгерской нотации обозначаешь? а если нам пофигу на тип, главное что бы квакало? ( duck typing - ну отзывалось на to_s например? )
или функция способна принимать аргументы нескольких типов?
будешь писать несколько функций? или динамически генерировать имена переменных?
Это хак, а хаки нужны только когда без них не обойтись.
Вас тоже сюда направляю: http://www.joelonsoftware.com/articles/Wrong.html
Послушайте, я не хочу пересказывать Спольски) Почитайте его, правда. Он ответит на все вопросы
All strings that come from the user must be stored in variables (or database columns) with a name starting with the prefix "us" (for Unsafe String). All strings that have been HTML encoded or which came from a known-safe location must be stored in variables with a name starting with the prefix "s" (for Safe string).
Ни намека на тип. Дальше больше:
So in Systems Hungarian you got a lot of dwFoo meaning “double word foo,” and doggone it, the fact that a variable is a double word tells you darn near nothing useful at all.
Надеюсь, Спольски ответил на все вопросы? ;)
> Надеюсь, Спольски ответил на все вопросы?
Прозреваю, это он про языки со статической типизацией, типа си. Там можно в любом адекватном ИДЕ, наведя мышку, посмотреть что за тип. К пхп это неприменимо.
• Keep functions short.
• Declare your variables as close as possible to the place where you will use them.
• Don’t use macros to create your own personal programming language.
• Don’t use goto.
• Don’t put closing braces more than one screen away from the matching opening brace.
1Don’t use macros to create your own personal programming language.
2Don’t use goto.
ЗЫ о УебКилл вернулся
прошу больше не разможатся делением пополам и ссорится как несинхронизированые треды)))
мля. даж выражаться не хочу, до меня все холивары были
pp obj
и прочие методы вывода все содержимого объекта
1. При попытке сделать кривой код (такой как в сабже) более поддерживаемым. Например, автор обращается к
$arrParameters как к массиву, хотя от того, что он имеет префикс, массивом может и не быть. К тому же эти
элементы в массиве могут и не существовать. И зачем обходить массив два раза? В общем код потенциально
бажный, и какую нотацию тут не используй лучше он не станет.
2. При особой любви к статической типизации. Вот зачем пытаться эмулировать фичи своего любимого языка там,
где их нет и они вообще не предусмотрены? Как вариант, нужно прекращать травмировать психику себе и
окружающим и юзать наиболее подходящие языки: C#, Java...
окружающим и юзать наиболее подходящие языки: C#, Java...
К сожалению это не всегда возможно.
А приведите пример ситуации, когда венгерка мешает
опять же, случай с счетчиками и короткоживущими переменными: префикс только удлинит название, а смысловой нагрузки не несет
Венгерка не сравнима по удобству с документированием (phpdoc) и не должна заменять его. К тому же
падает эффективность автокомплита.
Хе-хе, это единственная отличительная фишка бестиповых языков, и люди, юзающие такие языки, пытаются эту фишку обойти как баг. Борьба с собственным инструментом это так весело
Самый очевидный пример: я читаю код, смотрю по очереди на переменные и пытаюсь понять, что они содержат. Вместо этой информации я получаю информацию о типе. Этот факт заметно снижает понятность кода
Чем $strId хуже чем $id?
Почитайте Спольски, он сказал на эту тему больеш меня:
http://www.joelonsoftware.com/articles/Wrong.html