Вот код, чтобы получить полный путь к исполняемому приложению:
Windows:
int bytes = GetModuleFileName(NULL, pBuf, len);
if(bytes == 0)
return -1;
else
return bytes;
Linux:
char szTmp[32];
sprintf(szTmp, "/proc/%d/exe", getpid());
int bytes = MIN(readlink(szTmp, pBuf, len), len - 1);
if(bytes >= 0)
pBuf[bytes] = '\0';
return bytes;
В любом случае он оптимизируется во время компиляции, так что разницы во времени выполнения нет.
Как обычно, о стиле можно поспорить. Мои 50 центов: первый вариант (без явного другого) лучше, потому что меньше кода делает то же самое.
Конечно, в данном случае вы бы сделали
return a != 0;
... но я думаю, что вопрос носит общий характер.
Я бы не стал использовать else, если он лишний, любой разработчик должен понимать, что произойдет:
public void DoSomethingConditionally(Foo foo)
{
if (Bar)
{
foo.DoX();
return;
}
foo.DoY();
}
Я не согласен с людьми, которые хотят иметь только одну точку возврата для каждой функции, ваш функции должны быть небольшими, а несколько точек возврата улучшают, а не ухудшают читабельность.
Поскольку компилятор, вероятно, все равно уменьшит его до того же скомпилированного кода, делайте то, что вы считаете более "красивым".
Обратите внимание, что элегантность кода субъективна, поэтому не нужно догматически цепляться за тот или иной формат.
Стандарт кодирования LLVM и Стиль кодирования Mozilla утверждают, что else не следует использовать после возврата.
Если язык требует фигурных скобок для операторов if/else, я лично предпочитаю удалять оператор else и сопровождающие его фигурные скобки. Назначение кода будет таким же ясным, но код будет менее отступным, что (обычно) улучшает читабельность.
Как уже упоминалось, компилятор оптимизирует оператор else. Но если вы имеете дело с интерпретируемым языком, оператор else должен быть интерпретирован. В этом случае его удаление приведет к незначительному (очень незначительному) увеличению производительности.
Мне лично нравится Синтаксис:
/*Function header comments*/
Function(...)
{
/*English what the if is trying to achieve*/
If(...)
{
...
Return True; /*What this tells me*/
}
Else
{
...
Return False: /*What this tells me*/
}
}
Просто потому, что я нахожусь в ситуации, если я просто делаю
If(...)
Return True;
Else
Return False;
или
If(...)
Return True;
Return False;
или
(...)?Return True:Return False;
Что не так ясно,хотя с правильным комментарием один лайнер это круто, и если я все равно сравниваю, есть большая вероятность, что в будущем я все равно придумаю что-то, что должно произойти в этой области, я имею в виду, что я делаю это не только для ухмылки. Кроме того, если я найду особый случай, для которого требуется Else If, это просто вопрос добавления частей Else If.
if(statement)
result = true
else
result = false
return result
Неважно. Компилятор в любом случае выдаст один и тот же код. Проверьте, какому соглашению следует существующий код, а затем просто сделайте то же самое.
Лично я не ставлю «еще», потому что это очевидно. Я считаю, что дополнительное «еще» выглядит загроможденным.
Оба варианта будут работать одинаково на большинстве языков, но я думаю, что лучше всего использовать else
, чтобы сделать более очевидным, что когда ни один из if
/иначе, если
приведенные выше утверждения верны, сделайте это, даже если в этом нет необходимости.
Но, тем не менее, если у вас есть много кода ниже оператора if
, то вам не следует этого делать, так как это только превратится в огромный беспорядок с кучей ненужного else
заявления.
Я бы сказал, что это хорошая практика, потому что это немного упростит изменение кода. Например, допустим, вы хотели распечатать результат. Вы можете либо изменить его следующим образом:
if (a != 0) {
print "returning true"
return true
}
print "returning false"
return false
Что означает добавление отпечатка дважды, либо:
if (a != 0) {
retval = true
} else {
retval = false
}
print "returning ", retval
return retval
что означает добавление одного отпечатка, но это не будет работать без другого.
Конечно, это надуманный пример, но он показывает, как сделать код максимально удобным для сопровождения.
Конечно, "else" следует указывать явно.
Есть несколько причин, по которым 'else' следует объявлять явно:
По приведенной выше концептуальной причине это, конечно же, зависит от спецификации вашей функции. Для некоторых функций имеет смысл использовать такой код. Например "Функция предполагает, что посетитель не зарегистрирован, он регистрируется только если бла-бла-бла".
Но для другой проблемы, такой как «Если число делится на два, то оно четное, иначе оно нечетное», вы должны написать это явно, чтобы читатель (возможно, не программист) не запутался при чтении вашего кода. Так как читатель (может быть, математик) знает только такой инвариант и мало знает о языке программирования.
IMO - Если вы намерены вернуть true
при выполнении некоторого условия (например, что-то найдено), а затем, возможно, обработать данные другим способом, и, наконец, , когда ничего не найдено, вернуть false, вариант без else
понятнее.
Если возвращаемое значение зависит только от условия в if, вариант if-else выглядит лучше.
В этом случае просто верните результат выражения напрямую.
return (a != 0)
Но в целом я стараюсь избегать возврата из середины функции. Имейте один возврат на функцию.
Мое решение использовать или не использовать "else" зависит от моей семантической интерпретации "if" и, в некоторых случаях, от возвращаемого значения. В тех случаях, когда я чувствую, что «если» выбирает между двумя курсами действий или двумя возвращаемыми значениями, я буду использовать «иначе». В тех случаях, когда я чувствую, что это выбор между обычными действиями и «досрочным прерыванием», я пропущу остальное. В тех случаях, когда возвращаемое значение отвечает на вопрос «Что-то не удалось», я обычно расцениваю возврат ошибки как досрочное прерывание, даже если остается только вернуть успех, и, таким образом, пропустить «остальное». Если, однако, возвращаемое значение спрашивает: «Это что-то xxx», то я гораздо чаще включаю «иначе».
function DoSomethingConditionally(foo)
{
if (Bar)
{
foo.DoX();
return;
}
else
{
foo.DoY();
}
}
Мне нравится этот стиль, на случай, если мне понадобится что-то добавить позже.
Вы должны делать все, что делает код более понятным.
Просто вставьте еще и переходите к чему-то более захватывающему!