Вот на примере Друпала показательней всего, для чего так необходим realpath_cache. Плюс уменьшение cpu load и обращений к диску даже на небольших проектах, когда их много, в сумме даёт прирост производительности.
Если честно, то странное объяснение. Open_basedir не даёт 100% гарантии, что юзер не откроет каким-то способом файл за пределами ограничений open_basedir. Остаётся вопрос, зачем вы тогда вообще сделали такую опцию? В общем, внятного ответа, почему не хотят исправить баг нет.
Нет, задача стояла убрать постоянные обращения lstat в проверке путей мимо кеша realpath_cache. То, что он может включать safe_mode — это уже побочные фичи. Главное, что свою задачу он решает. В багрепорте Safe_mode упоминается лишь потому, что он оказывает такое же влияние на realpath_cache, как и open_basedir.
Это не вопрос объективного удобства, это вопрос привычек.
Вроде того. Вопрос привычки, которая сложилась, потому что так было удобнее. Именно поэтому обсуждение style-guide с определением «почему так».
Запретить использовать однострочники без фигурных скобок, значит, у вас ну никак не получается, а запретить использовать многострочные комментарии — раз плюнуть!
Понимаю, что пользователю доверять никогда нельзя, но это код, и вроде как человек, использующий его должен понимать, что он делает. Я не настаиваю на каком-то одном способе, просто интересно, почему так?
Хорошо, опишу, что я подразумеваю. Номер ноль пункт. Открывающие скобки есть не всегда и с этим надо смириться. Особенно, читая чужой код. В коде ниже я взял такой вариант (из комментариев) и в дальнейшем отформатировал для читабельности (сравните?). В первом пункте, фигурный скобки переносятся на новую строку, чтобы вертикально бегая глазами можно было легко найти её открытие без наведения на закрывающую скобку курсора (это экономит время). Второй пункт, следует из правила, что логически не атомарные блоки должны отделяться между собой одной пустой строкой для упрощения чтения. Любое условие if/while/for — это код атомарно не связанный с вложенным/зависящим от него блоком кодом.
пример
if (match->subtype & ST_TIME) {
trap_BotMatchVariable(match, TIME, timestring, MAX_MESSAGE_SIZE);
или
if (match->subtype & ST_TIME)
{
trap_BotMatchVariable(match, TIME, timestring, MAX_MESSAGE_SIZE);
И визуально, в конце закрывающая скобка как бы «обезглавлена». Если есть закрывающая, то есть и открывающая, и её приходится всякий раз искать.
Что касается однострочных комментариев, то я для подчинённых настаиваю использовать только их. Если нужно блок, то выделяем однострочными:
// *
// *
// *
// *
Это связано с тем, что С++ (да и php) не поддерживает nested multiline comments, и соответственно создаёт неудобства при дебагинге, когда нужно быстро закомментить функцию или несколько функций, приходится пролистать весь «закомментированный» код и добавить открытие/закрытие многострочного комментария. Используются только для личного дебагинга своего кода, в репозиторий заливаются лишь однострочные.
Обрамление пробелами, однозначные имена переменных и т.п. исходит из правила, что код — это книга, которую надо бегло читать, а не сидеть разбирать криптографию. Экономия пространства против читабельности не приветствуется. За многолетнюю практику так сложилось, что читать «пушисты» (объёмный) код гораздо легче, чем скомканный.
разница в форматировании текста
float BotGetTime(bot_match_t *match) {
bot_match_t timematch;
char timestring[MAX_MESSAGE_SIZE];
float t;
//if the matched string has a time
if (match->subtype & ST_TIME) {
//get the time string
trap_BotMatchVariable(match, TIME, timestring, MAX_MESSAGE_SIZE);
//match it to find out if the time is in seconds or minutes
if (trap_BotFindMatch(timestring, &timematch, MTCONTEXT_TIME)) {
if (timematch.type == MSG_FOREVER) {
t = 99999999.0f;
}
else if (timematch.type == MSG_FORAWHILE) {
t = 10 * 60; // 10 minutes
}
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
else if (timematch.type == MSG_FORALONGTIME) {
t = 30 * 60; // 30 minutes
}
else {
trap_BotMatchVariable(&timematch, TIME, timestring, MAX_MESSAGE_SIZE);
if (timematch.type == MSG_MINUTES) t = atof(timestring) * 60;
else if (timematch.type == MSG_SECONDS) t = atof(timestring);
else t = 0;
}
//if there's a valid time
if (t > 0) return FloatTime() + t;
}
}
return 0;
}
и
// * Function description
float BotGetTime(bot_match_t *match)
{
bot_match_t timematch;
char timestring[MAX_MESSAGE_SIZE];
float t;
//if the matched string has a time
if ( match->subtype & ST_TIME )
{
//get the time string
trap_BotMatchVariable(match, TIME, timestring, MAX_MESSAGE_SIZE);
//match it to find out if the time is in seconds or minutes
if ( trap_BotFindMatch(timestring, &timematch, MTCONTEXT_TIME) )
{
if ( timematch.type == MSG_FOREVER )
{
t = 99999999.0f; // means unlimited
}
else
if ( timematch.type == MSG_FORAWHILE )
{
t = 10 * 60; // 10 minutes in seconds
}
else
{
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
// много кода
}
if ( timematch.type == MSG_FORALONGTIME )
{
t = 30 * 60; // 30 minutes in seconds
}
else
{
trap_BotMatchVariable(&timematch, TIME, timestring, MAX_MESSAGE_SIZE);
// а тут нет скобок
if ( timematch.type == MSG_MINUTES )
t = atof(timestring) * 60; // to seconds
else
if ( timematch.type == MSG_SECONDS )
t = atof(timestring);
else
t = 0;
}
//if there's a valid time
if (t > 0)
return FloatTime() + t;
}
}
return 0;
}
а за подобные вещи надо бы наказывать. Тут вообще приходится останавливаться и разбираться, где условие, а где блок. Непонятно, для чего такая экономия.
if (timematch.type == MSG_MINUTES) t = atof(timestring) * 60;
else if (timematch.type == MSG_SECONDS) t = atof(timestring);
else t = 0;
ps. это только кусочек прижившегося и доказавшего свои плюсы над минусами, способа оформления.
я не прийду к GNU coding standards, потому не согласен c некоторой его частью, так же как и с частью Linux kernel c.s., которое используется далеко за ядром, и могу объяснить почему.
Например, Линус пишет:
Linux style for comments is the C89 "/*… */" style.
Don't use C99-style "// ..." comments.
Хочется спросить: why? Ну и ответ будет только один: because! Что это? Зачем? Ради совместимости с прошлым, которое уже надо забыть? Я понимаю, «When commenting the kernel API functions» — в ядре пишем так, как это задано изначально создателем, но люди кидаются применять это правило отовсюду. И ещё кучу всяких неудобств, которые Линусу удобны по привычке, а мне нет. Так вот, возвращаясь к вопросу про минусы: минусуют потому, что другая точка зрения?
Больше идеологический вопрос: вы перекладываете обработку неправильных параметров на функцию или оставляете это на совести передающего? Если на функцию, то какое поведение должна избирать функция: проигнорировать или выдать ошибку? А если и на пользователя, и на функцию, то как вы относитесь к постоянному дублированию проверок?
Вполне удобочитаемо даже с автоформатированием, если перенести скобку в новую строку: сразу видно где условие, а где блок, он отделяется пустой строкой. Я подсознательно сперва пропущу условие, если надо искать только ключевые вызовы функций. А в вашем примере прийдётся сперва выяснить, относится вызов к условию или уже к блоку if.
if (typeof a ! == "undefined" &&
typeof b ! == "undefined" &&
typeof c === "string")
{
call_function(a, b, c);
}
и переносите скобки! не заставляйте меня искать их даже с помощью подсветки
if ( node != null )
{ // я хочу знать, что тут скобка открылась, а не это if без скобки
while ( node.next != null )
{
node = node.next;
leafName = node.name;
}
} // мне удобнее и быстрее глазами пробежать вверх, чем диагоналями вращать в поисках подсвеченной скобки. Особенно, если это софт на продакшене, который надо срочно пофиксить через консольный /bin/nano
else
{
leafName = ””;
}
Основное правило: экономьте моё время.
Телефонные звонки я бы вообще запретил по максимуму. Большинство проблем решается письмами в то время, когда мне удобно.
Слово «Привет» всегда должно идти в первом сообщении, если до этого в этот день не писал сообщений этому человеку. Исключение могут составлять письма для коллег, с которыми вы уже лично поздоровались или в чате, или так заведено в компании.
В последующих сообщениях «привет» писать не нужно.
Вроде того. Вопрос привычки, которая сложилась, потому что так было удобнее. Именно поэтому обсуждение style-guide с определением «почему так».
Нет конечно, не везде, только в своих проектах.
Отлично поддерживаются в «плюсах», согласен, их там и надо применять вместо /* */. А где-то не поддерживаются (php).
или
И визуально, в конце закрывающая скобка как бы «обезглавлена». Если есть закрывающая, то есть и открывающая, и её приходится всякий раз искать.
Что касается однострочных комментариев, то я для подчинённых настаиваю использовать только их. Если нужно блок, то выделяем однострочными:
// *
// *
// *
// *
Это связано с тем, что С++ (да и php) не поддерживает nested multiline comments, и соответственно создаёт неудобства при дебагинге, когда нужно быстро закомментить функцию или несколько функций, приходится пролистать весь «закомментированный» код и добавить открытие/закрытие многострочного комментария. Используются только для личного дебагинга своего кода, в репозиторий заливаются лишь однострочные.
Обрамление пробелами, однозначные имена переменных и т.п. исходит из правила, что код — это книга, которую надо бегло читать, а не сидеть разбирать криптографию. Экономия пространства против читабельности не приветствуется. За многолетнюю практику так сложилось, что читать «пушисты» (объёмный) код гораздо легче, чем скомканный.
и
а за подобные вещи надо бы наказывать. Тут вообще приходится останавливаться и разбираться, где условие, а где блок. Непонятно, для чего такая экономия.
ps. это только кусочек прижившегося и доказавшего свои плюсы над минусами, способа оформления.
Например, Линус пишет:
Хочется спросить: why? Ну и ответ будет только один: because! Что это? Зачем? Ради совместимости с прошлым, которое уже надо забыть? Я понимаю, «When commenting the kernel API functions» — в ядре пишем так, как это задано изначально создателем, но люди кидаются применять это правило отовсюду. И ещё кучу всяких неудобств, которые Линусу удобны по привычке, а мне нет. Так вот, возвращаясь к вопросу про минусы: минусуют потому, что другая точка зрения?
и переносите скобки! не заставляйте меня искать их даже с помощью подсветки
Телефонные звонки я бы вообще запретил по максимуму. Большинство проблем решается письмами в то время, когда мне удобно.
вы не можете решить, что будет лучше, пока вам не предложат варианты, почему это может быть лучше.
В последующих сообщениях «привет» писать не нужно.