Оформление PHP-кода

Destruction · 30 Января 2006

Дело было так - сделал я модификацию, а мне сказали, что я оформлять нифига не умею - топаю в магаз за книжкой, читаю, топаю сюда делится.

Информацию взята из англиской книги, частично, весь текст является мои собственным переводом с некоторыми дополнениями и копирование строго настрого запрещено :-)

Итак, несмотря на свои познания в языке, очень легко написать такой код, который будет очень неудобочитаем и следовательно сложен в отладке. Незнаю почему, но некрасиво написанный код считается недостатком профессионализма - так не будем подмачивать свою репутацию.

Даже если код никто кроме программиста не увидит - согласитесь, тяжело через несколько лет модифицировать плохо оформленные программы.

Вообще стиль кодирования - крайне важная вещь, оссобенно, как в нашем случае, когда программу разрабатывает не один человек, а несколько. Вы навярняка заметили некоторые тонкие различия в коде IPB 2.1, как раз тонкость в различиях и достигается условленностью использовать один стиль кодирования, т.е. при написании модификации, крайне желательно использовать стиль кодирования такой же как и в исходной программе.

Я крайне рекомендую определится раз и навсегда, как вы будите кодировать свои программы, чтобы потом Вам было всё легче и легче читать свой код - привыкаешь со временем.

Отступы.

Отступы - одна из составных стилей кодирования и их нельзя ставить сегодня так завтра эдак. Например в языке Python наличие отступов является обязательным, а отсутствие корректных отступов не даст программе пройти анализ синтаксиса.

Рассмотрите следующий код:

if($month == 'september' || $month == 'april' || $month == 'june' || $month == 'november') { return 30;
}
else if($month == 'february') {
if((($year % 4 == 0) && !($year % 100)) || ($year % 400 == 0)) {
return 29;
}
else {
return 28;
}
}
else {
return 31;
}

И сравните вот с таким:

if($month == 'september' ||
  $month == 'april'		  ||
  $month == 'june'		  ||
  $month == 'november') {
return 30;
}
else if($month == 'february') {
if((($year % 4 == 0) && !($year % 100)) || ($year % 400 == 0)) {
	return 29;
}
else {
	return 28;
}
}
else {
return 31;
}

Согласитесь - второй код читать намного легче.

Есть два вида отступов:

1. Жесткая табуляция (hard tabs).

2. Мягкая табуляция (soft tabs).

1 - обычные символы табуляции.

2 - собственно вообще не табуляция, каждый отступ - это определённое количество пробелов. В глаза сразу бросается два очевидных минуса: 1 - долго ставить столько пробелов, 2 - каждый пробел весит по байту, т.е. мягкая табуляция больше будет занимать места. Но раз я упоминаю о этом виде отступов - значит у него есть и плюсы! Во втором случае отступы всегда представляются одинаково вне зависимости от настроек редактора, т.е. тот кто читает Ваш код, будет читать такой же код как и Вы, какой бы редактор он не использовал (ну не совсем конечно, но это мелочи). При использовании жёсткой табуляции соответсвенно могут возникнуть разные уровни отступов.

До прочтения книги я использовал жёсткую табуляцию и теперь понимаю, почему GiV сказал, что у меня проблемы с табуляцией - в другом редакторе возможно, я решил перейти на мягкую табуляцию, чтобы мой код был более удобочитаем.

Многие редакторы (т.е. не все) поддерживают автоопределение форматирования, путём использования специальных комментариях. Например код приведённый ниже автоматически настраивает редактор vim на использование мягкой табуляции и соответсвенно устанавливает её ширину в четыре пробела.

// vim: expandtab softtabstop=2 tabstop=2 shiftwidth=2

Ко всему прочему в vim есть команда :retab преобразовывающая жёсткую табцляцию в мягкую.

аналогичный эфект для emacs:

/*
* Local variables:
* tab-width: 2
* c-basic-offset: 2
* indent-tabs-mode: nil
*/

Лично я использую программу HomeSite и там такие извращения не нужны - редактор сам адаптируется к коду.

Длинна строки.

Ниже приведённая строка довольно длинная, поэтому нетрудно потерять приоритет проверяемых значений. В таких случаях стоит разбивать строку на несколько коротких.

if($month == 'september' || $month == 'april' || $month == 'june' || $month == 'november') { return 30;
}

if($month == 'september' ||
  $month == 'april' ||
  $month == 'june' ||
  $month == 'november')
{
return 30;
}

Так, же можно ввести отступ, чтобы обозначить связь с первой. Сравните выше приведённые строки на предмет удобоваримости.

Эта методика подойдёт и для параметров функций:

mail("admin@localhost",
   "My Subject",
   "My message content",
   "From: Destruction <admin@localhost>\r\n")

Как правило, следует разбивать строку содержащие более 80 символов, т.к. это ширина терминального окна Unix.

Использование пустого пространства.

Чтобы усилить удобоваримость программного кода, следует использовать пустое пространство. Например при помощи пустого пространства можно группировать операторы присваивания.

$lt = localtime();
$name = $_GET['name'];
$email =  $_GET['email'];
$month = $lt['tm_mon']+1;
$year = $lt['tm_year']+1900;
$day = $lt['tm_day'];
$address = $_GET['address'];

$name	= $_GET['name'];
$email   =  $_GET['email'];
$address = $_GET['address'];

$lt	= localtime();
$day   = $lt['tm_day'];
$month = $lt['tm_mon']+1;
$year  = $lt['tm_year']+1900;

Во втором примере, операторы удобно сгруппированы касательно логического назначения и выравнены операторы присваивания.

SQL-конструкции.

Все правила компановки и форматирования кода применимы как в PHP так и SQL-коде. SQL-запросы, оссобенно в системах баз данных, сложные подзапросы могут сбить с толку. Как и в случае с PHP, в SQL не следует опасаться пустого пространства и разрывов строк.

Рассмотрите такой запрос:

SELECT FirstName, LastName FROM employees, departments WHERE employees.dept_id=deparment.dept_id AND department.Name = 'Engineering';

Запрос конечно просто, но организован неудачно - легко потерять логику, его можно улучшить следующими способами:

1. Выделять ключевые слова прописными буквами.

2. Разбивать строки по ключевым словам.

3. Использовать псевдонимы таблиц для сохранения яноснти кода.

Пример использования этих способов:

SELECT firstname,
   lastname
FROM employees e,
 departments d
WHERE e.dept_id = d.dept_id
AND d.name = 'Engineering';

Управляющие конструкции.

Существует два типа управляющих конструкций: условия и циклы.

Возможность првоерить условие и выполнить действие в зависимости от результата позволяет организовать логику для принятия решений в программе.

Большая часть ситаксиса PHP взята из C#.

Следующий код выполняется корректно:

if(isset($name))
print "Hello $name !";

Однако не смотря, на то, что код верен, его лучше не использовать. Если опустить фигурные скобки, то впоследствии трудно модифицировать код, можно сбиться и забыть их воткнуть где следует, например:

if(isset($name))
print "Hello $name !";
$known_user = true;

Из отступов очевидно, для чего он предназначен, однако он не будет выполнятся как следует - переменной будет безусловно присвоена "правда".

Чтобы избежать путаницы, рекомендуется использовать в таких случаях фигурные скобки:

if(isset($name)){
print "Hello $name";
}
else {
print "Hello Guest";
}

Выше приведённый код намного легче модифицировать, так, что пожертвуем пару байт на фигурные скобки.

Необходимо выбрать один стиль использовать фигурных скобок. Существует три распрастранённых метода:

BSD-стиль:

if($cond)
{
// Some code
}

GNU-стиль:

if($cond)
 {
// Some code
 }

K&R-стиль:

if($cond){
// Some code
}

Обсуждать какой стиль лучше рекомендую только после того, как обратите всех католиков в проваславых христиан или наоборот.

Лично я предпочитаю использовать последний K&R стиль, он мне кажется наиболее удобным и лаконичным. Правда, когда условие разбивается на несколько строк, то лучше подойдёт BSD стиль.

Обзывательство

Кому-то может, показаться что это конкретно его дело, как обозвать переменную или функцию - вынужден расстроить, нифига -)

Например в коде:

function test($baz){
for($foo = 0; $foo < $baz; $foo++){
	$bar[$foo] = "test_$foo";
}
return $bar;
}

Крайне не понятны названия переменных, что значительно ухудшает читабельность кода, куда лаконичнее использовать следующий код:

function create_test_array($size){
for($i = 0; $i < $size; $i++){
	$retval[$i] = "test_$i";
}
return $retval;
}

Прочитав второй код, кому-нибудь возможно покажется, что это две совсем разные функции.

Для удобства, константы и глобальные переменные следует выделять заглавными буквами (например $CACHE_PATH или $TEMP_DIR), тогда сразу будет легко отлечить глоабную переменную от простой.

Замечу, что в IPB 2.1 "ipsclass" не написан заглавными буквами и это не ухудшает чтение кода потому, что он обычно вызывается из объекта $this, а вот в 2.0 $ibforums, $std, $sess и другие следовало бы сделать заглавными - это бы значительно упростило чтение кода.

Долговременные переменные должны иметь лаконичные, но описательные имена. Описательное имя способствует читабельности, и облегчает отслеживание переменных в больших кодах. Смотрите приведённый пример:

function clean_cache($expiration_time){
$cachefiles = list_cache();
foreach($cachefiles as $cachefile){
	if(filetime("$CACHE_PATH/$cachefile") > time() + $expiration_time){
		unlink("$CACHE_PATH/$cachefile");
	}
}
}

Имена временных переменных должны быть короткими и лаконичными. В циклах принято использовать i, j, k, l, m и n.

Сравним код:

$number_of_parent_indices = count($parent);
for($parent_index = 0; $parent_index < $number_of_parent_indices;
$parent_index++){
$number_of_child_indices = count($parent[$parent_index]);
for($child_index = 0; $child_index < $number_of_child_indices;
$child_index++){
	my_function($parent[$parent_index][$child_index]);
}
}

С таким кодом:

$pcount = $count($parent);
for($ i = 0; $i < $pcount; $i++){
$ccount = count($parent[$i]);
for($j = 0; $j <  $ccount; $j++){
	my_function($parent[$i][$j]);
}
}

Разумеется в данном случае лучше использовать foreach:

foreach($parent as $child){
foreach($child as $element){
	my_function($element);
}
}

Кроме того, в PHP есть функция, которая пременяет пользовательскую функцию ко всем элементам массива, ваще класс -)

Имена переменных из нескольких слов.

Как мы уже договорились, переменные должны иметь лаконичные названия.

Для отделения одного слова от другого есть два способа:

1. Писать имя следующего слова с болшой буквы:

$numElements = count($elements);

2. Использовать символ нижнего подчёркивания:

$num_elements = count($elements);

Внимательно проанализировав и вспомнив про константы, вспомним контстанту CACHE_PATH - интересно, как она будет выглядеть при использовании первого способа?.. Я бы рекомендовал именно второй стиль.

Для имён функций я бы дал те же рекомендации, что и для переменных.

Имена классов

Чтобы выделить классы, от других элементов, чтобы было ясно, что это класс а не задрипанная функция, автор книги рекомендует писать названия классов с большой буквы (как кстате в IPB и сделано).

Например:

class User{}
class Admin{}

Так же смотрите информацию про переменные из нескольких слов.

Запутанность в HTML.

В PHP есть два почти не различимых в ядре оператора - print и echo. Рекомендуется выбрать один.

Не рекомендуется использовать операторы PHP для вывода HTML кода - от этого он становится запутанным, PHP насколько мне известно славится полным встраивание в страницу.

Например вместо:

<?
echo "<table>";
echo "<tr><td>Name</td><td>Pos</td></tr>"
foreach($data as $el){
echo "<tr><td>{$el['name']}</td><td>{$el['pos']}</td></tr>";
}
echo "<table>";
?>

Лучше использовать:

<table>
<tr><td>Name</td><td>Pos</td></tr>
<?
foreach($data as $el){
?><tr><td><? echo $el['name']; ?></td><td><? echo $el['pos'] ?></td></tr>
}
?>
</table>

Я считаю это верным, как минимум потому, что в таком случае, мой редактор подсвечивает синтаксис HTML.

Комментарии:

Есть три вида комментариев:

1. Комментарии в стиле C#

/* Комментарий в стиле C#
* Всё еще комментарий
*/

2. Комментарии в стиле C++

// Комментарий в стиле C++

3. Комментарии в стиле Perl|Shell

# Комментарий в стиле shell

Рекомендуется избегать Shell стиля. Для больших блоко использовать стиль C#, а для однострочных - стиль C++.

Дополнительную информацию по созданию API-документации через комментарии с помощью phpDocumentor можно найти на странице проекта www.phpdoc.org

И будет наш код удобоварим и хорошенько переварен

Jax · 1 Февраля 2006

Спасибо, позновательно.

GiV · 1 Февраля 2006

Ниже приведённая строка довольно длинная, поэтому нетрудно потерять приоритет проверяемых значений. В таких случаях стоит разбивать строку на несколько коротких.

Не нужно делать таких конструкций!

Запрос конечно просто, но организован неудачно - легко потерять логику, его можно улучшить следующими способами:
1. Выделять ключевые слова прописными буквами.
2. Разбивать строки по ключевым словам.
3. Использовать псевдонимы таблиц для сохранения яноснти кода.

Да запрос простой, но идеологически не правильный, даже исходя из вашего пункта 3. И вообще 3-ий пункт спорен. Зачем мне алиас в запросе

SELECT * 
FROM table_name

Существует два типа управляющих конструкций: условия и циклы.
Возможность првоерить условие и выполнить действие в зависимости от результата позволяет организовать логику для принятия решений в программе.
Большая часть ситаксиса PHP взята из C#.

Никогда не слышал что PHP является сишарпоподобным языком...

Для удобства, константы и глобальные переменные следует выделять заглавными буквами (например $CACHE_PATH или $TEMP_DIR), тогда сразу будет легко отлечить глоабную переменную от простой.

А вы уже изначально знаете все свои глобальные переменные и даже их точное кол-во?

Разумеется в данном случае лучше использовать foreach

пукнул в лужу прям, как Мэтт в предпоследнем фиксе безопасности. Из тех двух кусков кода с for и foreach я бы выбрал с for, потому что он 100% работоспособный.

Ну и стили комментариев от C# до Shell это конечно мощно... Блочный, строковый, два стиля, да...

.silent · 1 Февраля 2006

и в самом деле, пример с длинной строкой и месяцами не шибко удачный.

хотя все же разбивать иногда нужно.

и все же, даже я не умею так занудно предираться. Пожалейте ребенка.

GiV · 1 Февраля 2006

Когда пишут азы, их пишут простым и грамотным языком. Да автор знает, да автор разобрался, но он так же не плохо умеет фантазировать придумывая "сишарп стили" и наводить читающих на неправильные (не в смысле, синтаксиса) мысли (а в смысле, семантики) -- примеры с for и foreach.

И вообще до нас уже кто то эти шаги сделал...

http://tony2001.phpclub.net/doc/standard/

Destruction · 3 Февраля 2006

Для танкистов, сие есть лишь моё личное мнение, которое я счёл весьма полезным и решил им поделится. Это вовсе не значит, что надо делать так, как написано.

Если хотите - давайте по-пунктам:

1. Ну-ну, это если Вам так удобно то и ладно, а Вы о других подумали? Пример с месяцами конечно ужасный, но тем не менее, надо делать так, как удобнее читать. Замечу, что я уже сказал, что это лишь мои советы, а Вы конкретно утверждаете, что не надо - ну дык КОНКРЕТИЗИРУЙТЕ !!! А то мы сейчас разведём спор, какая религия лучше и правильнее.

2. С алиасом код будет короче, а следовательно - яснее.

3. Не слышал - теперь услышал, я сие прочёл в книге, ко мне пожалуйста без претензий по-поводу того, что пишут в книгах. Если Вы так говорите о том, что узнали что-то новое - поздравляю, оригинально, я поражён.

4. Ну в большинстве случаев мне ясны мои переменные. Как думаешь, когда создаёшь переменную $CACHE_PATH для модуля КЭШирования чего-либо, ты знаешь, что она тебе понадобится в почти каждой функции или ты это узнаешь только тогда, когда понадобится? То-то же.. В данном случае я не говорю о том, что надо все глобальные переменные выделять, а большинство, чтобы они не лезли как серая масса - надо код выделять как можно более сильно, чтобы упростить его чтение, обычно в одной функции не используются все глоабнльные переменные и когда ты читаешь видя пару больших букв просто пропускаешь, уже догадавишсь, что там написано.

5. Насчёт foreach, хмм, ну незнаю, просто когда дописывал вдруг вспомнил - заглянул в книгу. Кстате расскажите мне, что не так с foreach ? Плохо работает? Я сейчас проверял - сработало вроде норм..

PS: А всё-таки приятно, что отпостили статью -)

Song · 3 Февраля 2006

2. С алиасом код будет короче, а следовательно - яснее.

Перечитайте ещё раз что вам сказал GIV выше. Там алиас не нужен вообще. И уж к слову говоря с алиасом в данной ситуации будет только длиннее.

5. Насчёт foreach, хмм, ну незнаю, просто когда дописывал вдруг вспомнил - заглянул в книгу. Кстате расскажите мне, что не так с foreach ? Плохо работает? Я сейчас проверял - сработало вроде норм..

угу, работает, если $data что-либо содержит. Именно это видимо GIV имел ввиду когда сказал про лужу..

Добавлено:

Просто все забывают что foreach выводит ошибку в случае когда нет "for each", а for'у - пофик, потому как его итерации просто не начнут выполняться.

d1pro · 3 Февраля 2006

Не слышал - теперь услышал, я сие прочёл в книге, ко мне пожалуйста без претензий по-поводу того

Я думаю имеется ввиду, что php по своему синтаксису пренадлежит к семейству C-like (си-подобных) языков, а не конкретно к C#, ибо сам сишарп был не так давно разработан и наследует синтаксис все от того же C.

угу, работает, если $data что-либо содержит

Я для этого пишу примерно так

if ( count( $data ) )
foreach( $data as $k => $v )
{
   //some code here...
}

В общем-то помогает

Destruction · 4 Февраля 2006

Так, это уже интересно, вот JS-скрипт (его тестать быстро и удобно - ИМХО).

<script type="text/javascript">
var query1 = "SELECT FirstName, LastName FROM employees, departments WHERE employees.dept_id=deparment.dept_id AND department.Name = 'Engineering';"
var query2 = "SELECT firstname,\nlastname\nFROM employees e,\ndepartments d\nWHERE e.dept_id = d.dept_id\nAND d.name = 'Engineering';";
if(query1.length > query2.length){
alert("Первый запрос больше на "+String(query1.length-query2.length)+" символов.");
}
else{
alert("Второй запрос больше на "+String(query2.length-query1.length)+" символов.");
}
</script>

Типа JS считать не умеет?..

Хех, я думал он работает как-то криво, а вы про это.. Ну я привёл пример, для конкретного случая, а в конкретно случае подразумевалось, что аргументы есть. Если аргументов нет - надо отрастить руки как у d1pro.

2d1pro, руки сколько метров, много знаешь вроде..

SphinX · 8 Марта 2006

1. Комментарии в стиле C#
/* Комментарий в стиле C#
* Всё еще комментарий
/*

WTF?

/* COMMENTS BLOCK OPEN
Here come my l33t comments
Here come more comments
COMMENTS BLOCK CLOSED */

Рекомендуется избегать Shell стиля.

Почему?

Блочный стиль комментирования куда опасней - нельзя вкладывать блоки комментариев друг в друга, нужно быть аккуратным при комментировании регулярных выражений, т.к. там может встретиться последовательность символов */, которая замочит блок комментариев.

Следует отметить, что астериски в блочных комментариях используются для юзания phpdoc.

Лично я использую программу HomeSite и там такие извращения не нужны - редактор сам адаптируется к коду.

Вай, напросишься на холивар...

Destruction · 8 Марта 2006

Я не утверждаю, что всем надо юзать HomeSite, просто он удовлетворяет моим требованиям, холивар - давайте в отдельную тему, что не умеет HomeSite из нужного, мне аж самому интересна.

С комментарием описался - прошу прощения, пойду поправлю.

ЗЫ: Как же тема так долго на премодерации исела и никто такой баг не отловил?..

DANMASTER · 8 Марта 2006

Во первых PHP и JavaScript по синтаксису подобны C, но не в коем случае C#, т.к. он был выпущен намного позже.

Во вторых оформление полезно только для широких кодов т.е. больших скриптов, например мои скрипты не малые по 20кб текста очень не удобно читать без форматирования.

Destruction · 8 Марта 2006

Последний факт говорит о Вашем не проффесионализме.

Я с некоторых пор, коды даже на 1 экран пишу красиво и понятно, т.к. через пару дней начинаю их всяческих улучшать, доводить до совершенства.

DANMASTER · 8 Марта 2006

Не совсем вас понял.

SphinX · 8 Марта 2006

DANMASTER, если писать код красиво и культурно - то писать его красиво и культурно ВСЕГДА, вне зависимости от того, пишешь ты гостевуху или сложный фреймворк. Двойные стандарты в культуре программирования недопустимы, имхо.

DANMASTER · 8 Марта 2006

А я разве сказал, что для мелкого кода применять не надо?

Destruction · 9 Марта 2006

А разве, кто-то сказал, что ты сказал, что не надо? -)))

Я просто заметил, о твоём непрофессионализме, в связи с тем, что мелкий код ты не оформляешь.

SAT · 10 Марта 2006

Destruction

как я пишу, так это меня приучили однажды одногрупники, потом это помогло мне отладить кучу программ... вообщем пошло от C++...

вот приведено куча кода в этом топике, для меня, единственно правильный в культуре написания я вижу код который написал d1pro

как только поглядел первый пост так в глаза первое бросается это вот это

foreach($parent as $child){

наверное после этого легко искать не закрытую скобку?

правильно:

foreach( $parent as $child )
{

все идет скобочка под скобочкой, пробелы расставлены, тубуляции и тогда год получается не сгромаждается в непонятный набор символов текст, а превращается в легко читабельный код

и еще это осмысленное название переменных...

больше бесит когда вижу в коде примерно такую конструкцию:

} else {

посмотрим на код Мэтта:

//--------------------------------

if( $some_if )
{
//longest code
}

//--------------------------------

отделение логических конструкций, это изначально когда я стал изучать форумы стало именно мои решающим фактором что я остался именно с IPB, а не с воблой... именно IPB меня привлекло в культуре написание кода

по правилу хорошего тона в файле с кодом должно быть 80% коментариев а только 20% кода(об этом пишут, но никто этого не делает), но я такого еще не стречал

понимаю коменты лень ставить, но для исправления этого бага попишите на ASMе, там вы код не через неделю две забудете а через 5 минут...

вообщем это лишь мое ИМХО... можно и не соглашаться с ним...

1. Комментарии в стиле C#
[/code]

ага
///<summary>
///comments....
///</summary>
SphinX

согласен, ведь всегда приятно смотреть на хороший код, а не на тот который из-за нечитабельности будет забыт через 2 недели и потом придется потратить часы на вспоминание "чего ж я тут натворил?"

Destruction · 10 Марта 2006

2SAT, не разводи споры на религиозную тему.

Мне лично не нравится стиль BSD - при его использовании, влезает мало кода на страницу, а при использование K&R, код для меня вполне удобочитаем и влазает его больше.

Просто каждому надо своё, ИМХО.

SAT · 10 Марта 2006

Destruction

ну прямо пальци ввером и в дверь можно войти только боком...

читайте:

Бьярн Страуструп (C++)

S. McConnel "Code Complete"

A.Hunt, D.Thomas "The Pragmatic Programmer"

Э. Дейкстра Дисциплина программирования

после прочтения вопросы сами собой отпадут

xRay · 10 Марта 2006

Destruction

if($month == 'september' || $month == 'april' || $month == 'june' || $month == 'november') { return 30;
}

Так и хочется воскликнуть о парсере о бедном замолвите слово...

1. Нормально и понятно воспринимается

2. Парсится быстрее (см. код самого движка php)

Чем вот это тихий ужас... раскиданный по строчкам...

А вообще возьми вот это и не парься

http://www.waterproof.fr/products/phpCodeBeautifier/

Этот оформитель кода и с SVN можно свзять вообщем руль, советую.

Ну и сам PHPEdit не плох

И в оформительстве кода юзать только BSD-стиль в таком коде более понятна вложенность операторов чем в K&R-стиле

А про то что больше кода влазит с K&R-стилем на экран ну это просто ЛОЛ да и только

Destruction · 11 Марта 2006

Прошу модераторов топик разделить - пошла война, чья религия лучше.

ЗЫ: Какой такой лол? Я ведь правильно всё говорю - не над чем смеятся !

xRay · 11 Марта 2006

Я все аргументированно описал см. мой пост который выше твоего

Destruction · 11 Марта 2006

Я все аргументированно описал см. мой пост который выше твоего

Аргументровано? Покажи необходимые куски кода парсера пхп, аргументщик !

Ты просто не понимаешь, что спор о стиле программирования, программах используемых для этого и о том, чья работа сложнее - дизайнера или художника очень похож спору, какая религия лучше.

DANMASTER · 22 Марта 2006

Я просто заметил, о твоём непрофессионализме, в связи с тем, что мелкий код ты не оформляешь.

Неправильно ты заметил.

Войти

Оформление PHP-кода

Рекомендуемые сообщения

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Ссылка на комментарий

Поделиться на других сайтах

Присоединиться к обсуждению

Важная информация