Автор оригинала: fixxxer 
WP
ну у тебя реально код сложно читается, поверь 

я понимаю что тебе так удобно/привычно, но при работе в команде обычно принято более каноническое оформление 

ну и методы некоторые неприлично длинные
		
 
		
	 
Согласен. Большая часть имен переменных состоит из одной буквы:
	
	
	
		PHP:
	
	
		public function prepare_mixed($mixed,$mode = 1)
 {
  if (is_array($mixed))
  {
   if ($mode == 1 || $mode == 2)
   {
    $r = '';
    $s = sizeof($mixed);
    $i = 0;
    foreach ($mixed as $k => $v)
    {
     if (!ctype_digit((string) $k)) {$as = $v; $v = $k;}
     else {$as = '';}
     if (strpos($v,'.') !== FALSE)
     {
      $e = explode('.',$v);
      $r .= '`'.$e[0].'`';
      if (isset($e[1])) {$r .= '.`'.$e[1].'`';}
      if (isset($e[2])) {$r .= '.`'.$e[2].'`';}
     }
	 
 По этому поводу все хорошо расписано Макконнелла в Совершенном коде.
-------------------------------------------------------
Достаточно странные соглашения об именовании методов...
	
	
	
		PHP:
	
	
		 public function _restore_memorycache($p)
	 
 <...>
	
	
	
		PHP:
	
	
		public function fetchRowset()
	 
 Обычно с _ начинаются имена внутренних методов. protected или private. Регистр в первом случае почему-то отличается от второго.  Логичнее было бы ожидать (_restoreMemoryCache и fetchRowset) или на худой конец (_restore_memorycache и fetch_rowset) но не такой разнобой.
-------------------------------------------------------
На мой взгляд, неудачно реализован механизм кеширования. Из-за кучи этих  
	
	
	
		PHP:
	
	
		if ($this->query->cacheStorage == 'memory')
	 
  я не могу просто взять и легко добавить свой собственный механизм кеширования.
	
	
	
		PHP:
	
	
		if (defined('SMARTDB_MYSQL_LOADED')) {
return self::$db = new SmartDB_mysql();
	 
 Почему бы не воспользоваться include_once вместо череды if, проверяющей, доступны ли функции?
-------------------------------------------------------
	
	
	
		PHP:
	
	
		public function begin() {
    return $this->query('BEGIN');
}
	 
 Если движок претендует на универсальность по отношению к серверам баз данных, я бы назвал этот метод startTransaction, согласно стандарту, чтобы не смущать разработчиков. BEGIN - это чисто MySQL вариант.
-------------------------------------------------------
	
	
	
		PHP:
	
	
		$query = 'SELECT' . ($this->type !== '' ? ' ' . $this->type : '') . ' ' . $this->prepare_mixed(
$this->fields, 1) . ($this->from !== NULL ? ' FROM ' . $this->prepare_mixed(
$this->from, 2) : '') . $join . ($this->where !== NULL ? ' WHERE ' . $this->prepare_mixed(
$this->where, 3) : '') . (($this->limit !== NULL || $this->offset !== NULL) ? ' LIMIT ' .
($this->offset > 0 ? $this->offset . ',' : '') . $this->limit : '');
	 
 Долго смотрел на это и понял, что мне так не написать...
-------------------------------------------------------
Никаких абстрактных классов или хотя бы интерфейсов. Т.е. написать драйвер под другой тип БД без автора невозможно (вернее, конечно, возможно, но не рентабельно), поскольку код ВООБЩЕ не документирован.
-------------------------------------------------------
	
	
	
		PHP:
	
	
		function flock_wait($fp, $lock) {
			if ($fp === FALSE) {
				return FALSE;
			}
			while ( TRUE ) {
				if (flock($fp, $lock)) {
					return TRUE;
				}
				usleep(100000);
			}
		}
	 
 Эта реализация меня немного удивила. У flock есть третий параметр, который можно установить в 1, чтобы вызов flock оказался блокирующим скрипт на время, пока блокировка не освободится. Тут же мы видим цикл, отнимающий время процессора (несмотря на usleep).
-------------------------------------------------------
	
	
	
		PHP:
	
	
		$t2 = unpack('Nl', substr($r, $seq + 8 * $i + 4, 4));
	 
 Собственный механизм сериализации (если я правильно понял код) - это здорово. Но вот сложный он очень... Попробовать бы сравнить его по скорости с serialize...
-------------------------------------------------------
Никакого использования механизма исключений... Везде нужно помнить и проверять коды возврата.
-------------------------------------------------------
Интегрировать в движок, скажем, профайлер или логгер slow-queries будет довольно трудно....
-------------------------------------------------------
В целом, код показался мне писанным с тем расчетом, что его никогда никто не будет читать, а тем более использовать. Во всяком случае, я бы не решился. Читая код ADODB (который тоже временами бывает весьма путанным), я хотя бы понимаю, что он делает. А тут...
Наверное, это движок чисто для внутреннего использования.