Единственное, что понравилось - код на темном фоне. ИМХО панель слишком широкие, феерическое ШГ в заголовках табов/окон, вистовые обрамление смотрится ничего так, хотя ИМХО тоже не в тему, корзина на рабочем столе не нужна. Вот в общем все. И да, реквестирую обоину.

ШГ в заголовках и строке меню. Да и везде в общем, кроме кода.

PHP

Vista Classic тема.

Американский матрас со звёздочками в качестве переключалки. Уныло.

>Американский матрас со звёздочками в качестве переключалки.

Да, точно, забыл про матрас сказать.

Comics не нужен!
Прозрачность не нужна.
Иконки ужасные.
Что может джини, чего не может Vim?
Комментарии на русском... Только для себя пишешь?

Ощущение какого-то пздц'а, наступающего со всех сторон.

Yellow Leaf - не?

Да. Для себя. И да - Yellow Leaf.

Иконки и Comic Sans - у меня в целом мультяшный стиль. И он мне нравится. Как-то успокаивает и позволяет отдохнуть.

У Geany очень приятная интеграция с SVN, автодополнение кода, какое-то подобие менеджера проектов и ещё кое-какие плюшки, которые конечно можно поиметь в VIM, но мне лень.

Прозрачность (ИМХО) в разумных пределах наоборот смотрится симпатично.

И да, реквестирую обоину.

Обоину взял тут: http://gnome-look.org/content/show.php?action=content&content=124769

>Обоину взял тут: http://gnome-look.org/content/show.php?action=content&content=124769

Благодарю.

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

Ты в .inc хранишь код? И настройки тоже? Учти — хтакссесс может отвалиться и пароль от бд утечёт наружу.

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

Коменты в коде доставили. Особенно последний. :)
У нас в универе так двоечники каждую строку комментировали чтобы перед преподом их читать.

Вся эта хренота:

return $db->select($newstablename,array('id'=>array(array_map('intval',$ids),'<-')));

Но комментарии — круто, да.

http://bancomicsans.com/

Пыхеры, сцуко, опасные

Не пугай людей своим кодом.

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

комМЕнтарии

Учти — хтакссесс может отвалиться и пароль от бд утечёт наружу.

Ну как бы я сам админю сервер, так что вероятность того что он отвалится достаточно мала. Я сам себе не враг:)

генератор запросов и слой абстракции от базы данных

Давно думаю над этим. Пока ещё дальше мыслей не ушло. Хочется сделать что-то действительно удобное.

У нас в универе так двоечники каждую строку комментировали чтобы перед преподом их читать.

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

Давно думаю над этим. Пока ещё дальше мыслей не ушло. Хочется сделать что-то действительно удобное.

Над моим синтаксисом что думаешь? Хотя это я наврал, метод называется „read“, а не „select“, и выглядит так:

read($table,$conditions=array(),$order=false,$limit=false,$offset=0,$reverse=false);
...
read_data($table,$columns=array('*'),$conditions=array(),$order=false,$limit=false,$offset=0,$reverse=false,$distinct=false)
...
insert($table,$arr);
...
update($table,$conditions=array(),$arr=array());
...
swap($table,$val0,$val1,$key);

Ну и так далее. Там же джойны.

Условия — массив (карта) ключ=>значение, или ключ=>(значение,оператор), где оператор - =, !=, <, >, <=, >=, ~ (LIKE), ~~(= регистро-независимо), <- (IN), ~<- (NOT IN) ну и т.д.

Вставлять можно построчно (ключи — имена столбцов), а можно большой двумерный массив с числовыми индексами, где имена столбцов — в первой строчке.

При обновлении можно таким же образом как в условиях сказать, например, /= или ещё что-нибудь.

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

Ну и далее в том же духе.

Я сам себе не враг:)

А по поводу конфигов — вдруг потом придётся переносить куда-то, или ешё чего. Я не вижу смысла делать расширение не „.php“. Хотя про запрет в хтаксессе забывать в любом случае не стоит, потому что на моей памяти были случаи, когда на хостингах обработчик php отваливался и выдавал код для доступных файлов.

на моей памяти были случаи, когда на хостингах обработчик php отваливался и выдавал код

Ну я специально свой сервер ломать не собираюсь:)

Над моим синтаксисом что думаешь?

В целом ничего. Но read_data у тебя через чур сложная:)

read($table,$conditions=array(),$order=false,$limit=false,$offset=0,$reverse=false);

Не помню уже, когда у себя последний раз к БД напрямую обращался... ORM рулит. А так - какой смысл делать отдельными параметрами limit/order/offset и запоминать их порядок, когда можно занести их в $conditions?

У меня оно так делается:

$dbh = new driver_mysql('FORUM');

$posts_data = $dbh->select_array('posts', array('topic_id' => $topic, 'order' => '-posted', 'limit' => 50));

$posts_data = $dbh->select_array('posts', array('topic_id' => $topic, 'order' => 'posted', 'page' => $page, 'per_page' => 25));

Оно напрямую и не вызывается нигде, хотя и public.

А зачем смешивать две различных сущности — фильтры и опции. Возможно опции и стоит внести в массив параметров (подумаю над этим), но объединять с фильтрами зачем?

А вообще, по большому счёту, поверх этой прослойки есть ещё одна — в каждом модуле, использующем бд.

select($row=array(),$order=false,$limit=false,$offset=0,$reverse=false) {
	return $this->m('db')->read($this->_m,$row,$order,$limit,$offset,$reverse);
}
...
insert_data($row=array()) {
	return $this->m('db')->insert($this->_p.'data',$row);
}

Ну и так далее. Они работают уже с соотвествующими таблицами, вида префикс_бд + префикс_модуля + таблица в модуле.

Единственное, что мне однозначно понравилось — минус при сортировке назад.

Смотря что для тебя большой проект. Но я гарантирую тебе, что комментарии в духе «возвращаем результат» тебе ничем не помогут, и размер проекта тут ни при чем.

А зачем смешивать две различных сущности — фильтры и опции

Для борьбы с преждевременной оптимизацией ;)

Эти сущности очень хорошо различаются. А искусственное разделение сильно усложняет синтаксис. Оно надо?

Возможно опции и стоит внести в массив параметров (подумаю над этим), но объединять с фильтрами зачем?

Затем, что в PHP тяжеловесен синтаксис параметров. И писать два array() в одном вызове - это уже излишество. А если один из параметров (который в списке будет первым) будет пустой - писать пустой array()? Как ни крути, а получается некрасиво :)

А вообще, по большому счёту, поверх этой прослойки есть ещё одна

По большому счёту с БД должен работать бэкенд ORM'а. И тебя не должны волновать БД, таблицы, префиксы...

Единственное, что мне однозначно понравилось — минус при сортировке назад.

Там много подобных оптимизаций. Например, часто нужна выборка по field IN(...). Можно сделать так:

$ids = array(1,2,3,10,20,37); // ...

$data = $dbh->select_array('posts', 'topic_id IN' => $ids);

>Но я гарантирую тебе, что комментарии в духе «возвращаем результат» тебе ничем не помогут

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

Но я гарантирую тебе, что комментарии в духе «возвращаем результат» тебе ничем не помогут, и размер проекта тут ни при чем.

Тут уже просто чтобы не расслабляться. Написал строку кода - напиши что она делает. Святое правило.

>Написал строку кода - напиши что она делает. Святое правило.

Нужно срочно от этого правила избавляться. Мало того, что это удваивает объём писанины и снижает концентрацию на основной задаче, так это ещё и затрудняет чтение кода через некоторое время. Придётся в тоннах комментариев искать реально требующие внимания вещи.

И кто же это святое правило придумал? Отцы Unix с ним не согласны.
И вообще, рекомендую почитать: http://www.ozon.ru/context/detail/id/1927500/

А разве mysql_query еще используется? Везде сейчас вижу как минимум PDO.

>А разве mysql_query еще используется? Везде сейчас вижу как минимум PDO.

PDO заметно медленнее. Зачем терять в производительности, когда в нормальных проектах всё равно с уровнем прямых запросов всё равно не сталкиваешься?

Штирлиц еще никогда не был так близок к провалу.

Ох щи! Сделайте меня развидеть это!

а мой скриншот страшнее http://blindage.org/?p=1840

Шрифты УГ, значки УГ, обрамление УГ.

А разгадка одна — безблагодатность.

Написал строку кода - напиши что она делает. Святое правило.

Это плохое, негодное правило. Разве из строчки уже не видно что она делает? Если не видно - значит у вас: 1. Код плохо структурирован, можно попробовать его несколько реорганизовать (например extract method). Есть достаточно простое правило - код в пределах функции должен иметь примерно одинаковый уровень абстракции.

2. Имена функций и переменных неочевидны.

имхо, должно получиться примерно следущее:

$ids_list = prepareIds();

$result = array();

if (sizeof($ids) > 0) { 
    $result = getNews(); 
} 

return $result; 

и да, курсивный шрифт в заголовках табов в Geany ужасен.

> Написал строку кода - напиши что она делает. Святое правило.

Это плохое, негодное правило.

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

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

улыбнуло:

Делаем входные данные безопасными

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

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

Собственно говоря, если ты не смог прочесть алгоритм, то чего ты вообще забыл в программировании?

опасный вы человек!

> return $db->select($newstablename,array('id'=>array(array_map('intval',$ids),'<-')));


да, тяжко без хотя бы простейшего ORM.

Код ужасен. Про лишние комментарии тебе уже рассказали. Еще одна быдлокодерская ошибка: проверка входных данных в середине функции.

Это хорошее правило в случае если человек пишет на том же пыхпыхе раз в год

на чем бы человек не писал код в остальное время комментарии типа:

// если a больше 0
if (a>0)

не нужны. так же как и коментарий «освобождаем ресурсы» перед функцией mysql_free_results и «выполняем запрос» перед mysql_query - разве из названий функций не видно?

Всё пиндец, кроме значков. Дай ссылку, MooSE

yet another comment: передоз камментов, как будто в гости капитан очевидность заходил

PS ylsoftware снаружи лучше чем изнутри )))

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

А где тогда хранить пароль от БД, как не в файле?

начните писать на каком либо фреймвёрке php и такой «код» поддерживать не придется.
Советую yii - http://www.yiiframework.com/ http://www.yiiframework.ru/

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

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

В данном случае явно перебор.

Человеку, который пользуется таким оформлением на своем десктопе, нельзя доверять дизайн сайтов. Это просто вырви_глаз.exe, особенно comic sans ms и вистодекорации.