Тот, кто это будет читать, не знает, понимаете ли вы, чего хотите. Скобки (если ими не злоупотребляли) дают наглядное визуальное представление приоритета и показывают, что именно вы хотели от среды исполнения, тогда как при беглом просмотре && и || слабо различимы, требуя более пристального внимания и затрудняя понимание логики при разборе пачки схожих условий.
То, что данное предупреждение добавили в C, говорит о том, что ошибки, завязанные на непонимании приоритета, слишком часты. Я сильно сомневаюсь, что отсутствие предупреждения могло сделать их более редкими. Отсутствие предупреждения также не могло сделать && и || более различимыми.
Предупреждение, выдаваемое компиляторами, C имеет свои причины. То, что вы пишете не на C, не означает, что в JavaScript эти причины каким‐то магическим образом прекратили своё существование: синтаксис языков при записи комбинаций условных выражений достаточно схож, несмотря на множественные различия вроде результата выполнения &&/||.
В C вам на такой код выдадут warning. И будут правы: используйте скобки, иначе понять, что здесь происходит, будет сложно. Ещё сложнее будет понять действительно ли вы хотели написать то, что написали, или вы находитесь в заблуждении относительно приоритета.
Оба варианта получат предупреждение о неявном определении функции. Ваше счастье, что такое определение вообще корректно; и то оно корректно только из‐за того, что обе функции возвращают int:
(zyx-desktop:zyx:~) 1 % echo $'main(){puts("Hello word!");}' | clang -x c -
<stdin>:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main(){puts("Hello word!");}
^~~~
<stdin>:1:8: warning: implicit declaration of function 'puts' is invalid in C99 [-Wimplicit-function-declaration]
main(){puts("Hello word!");}
^
2 warnings generated.
(zyx-desktop:zyx:~) 1 % echo $'main(){puts("Hello word!");}' | gcc -x c -Wall -
<stdin>:1:1: предупреждение: по умолчанию возвращаемый тип функции - «int» [-Wreturn-type]
<stdin>: В функции «main»:
<stdin>:1:1: предупреждение: неявная декларация функции «puts» [-Wimplicit-function-declaration]
<stdin>:1:1: предупреждение: control reaches end of non-void function [-Wreturn-type]
Кстати, видите первое предупреждение? Функция без возвращаемого типа должна возвращать int. А что возвращаете вы? Я не думаю, что приводить в качестве первого примера не корректную программу — хорошая идея.
Если компилировать как C++ (я помню, что EuroElessar сказал «Если уж говорить про Си») будут тоже две, но ошибки:
(zyx-desktop:zyx:~) 1 % echo $'main(){puts("Hello word!");}' | clang -x c++ -
<stdin>:1:1: error: C++ requires a type specifier for all declarations
main(){puts("Hello word!");}
^~~~
<stdin>:1:8: error: use of undeclared identifier 'puts'
main(){puts("Hello word!");}
^
2 errors generated.
(zyx-desktop:zyx:~) 1 % echo $'main(){puts("Hello word!");}' | gcc -x c++ -
<stdin>: В функции «int main()»:
<stdin>:1:26: ошибка: нет декларации «puts» в этой области видимости
В первой ссылке по запросу bcache HOWTO утверждается, что как местом расположения кэша, так и местом расположения HDD может быть любое блочное устройство. Любое — это значит, что вы можете поставить там RAID0 из SSD, LVM раздел или даже другую пару устройств под управлением bcache (хотя это и не имеет смысла).
Другой вопрос, что именно надо поставить, чтобы уменьшить время доступа (в интернете утверждают, что кэшировать на RAID0 из SSD не имеет смысла, так как это увеличит задержки; не знаю, насколько можно им верить). Но тот же LVM может склеивать диски последовательно ⇒ не увеличивая время доступа. Хотя, конечно, если бы данные по дискам раскидывал сам bcache, то можно было бы оптимизировать алгоритм.
А, не заметил -w в git help annotate. Bazaar не получил этого умения после пересмотра bzr help annotate. Subversion умеет через --extension. Хочется поставить себе минус.
Написать дополнение к Vim, проверяющее ширину текста при табуляции, равной восьми — дело пяти минут.
function FindTooLongLines()
if &textwidth == 0
return 0
endif
let saved_winview=winsaveview()
let saved_tabstop=&tabstop
let saved_lazyredraw=&lazyredraw
set tabstop=8 lazyredraw
let ret=0
let pattern=printf('\%%>%uv.*', &textwidth)
try
1
while search(pattern, 'We')
echohl ErrorMsg
echomsg printf('Line %u is too long: %s', line('.'), substitute(getline('.'), '^\s*', '', ''))
echohl None
let ret=1
endwhile
finally
let &tabstop=saved_tabstop
let &lazyredraw=saved_lazyredraw
call winrestview(saved_winview)
endtry
return ret
endfunction
autocmd BufWritePre * :if FindTooLongLines()|throw 'Too long lines found'|endif
% hg help annotate
<…>
-w --ignore-all-space игнорировать пробельные символы при сравнении строк
-b --ignore-space-change игнорировать изменения в количестве пробельных
символов
-B --ignore-blank-lines игнорировать изменения, состоящие только из пустых
строк
<…>
Как вы думаете, что делают эти ключи в hg help annotate? Другой вопрос, что их нельзя использовать вместе с языками, где важны отступы. И такой возможности нет в git, bazaar и svn. И наверняка почти во всех остальных VCS. Против изменений «скобочек» эти ключи также не помогут.
Так что идея в целом плохая. Но история, тем не менее, в Mercurial «потеряется» не фатально.
Договорились использовать табуляцию — используем табуляцию все. В чём проблема?
Я не вижу, как табуляция сделает код единообразным. Я также не вижу, как пробелы сделают его таким. Convention’ы единообразным код сделают, что бы вы в них не написали про отступы.
Если вы про то, что в разных редакторах отступы будут занимать одинаковое место, то в этом я не вижу совершенно никакого смысла. Код в разных редакторах всё равно будет выглядеть по‐разному; и даже в одном редакторе при разных настройках. Почему бы тогда не написать, что код надо смотреть только в {какой‐то редактор} версии {какая‐то версия} с шрифтом {какой‐то моноширинный шрифт} и начертанием {какое‐то начертание} размера {какой‐то размер} и цветовой схемой {какая‐то цветовая схема} и настройками {какие‐то другие настройки редактора, влияющие на отображение}? Тогда код будет выглядеть единообразно. Если вас не пошлют.
Ничего хорошего в том, чтобы код выглядел в разных проектах одинаково, я не вижу. Человечество выживает за счёт разнообразия, а не за счёт единственности. Единственное но: если вы используете не тот стиль именования, что принят в некотором языке, то код в проекте будет выглядеть неоднородным за счёт внешних библиотек. А скобки, отступы, длина строк, способ разбиения длинных строк и тому подобное можно иметь какими угодно.
Разделяйте отступы и выравнивание. Отступы можно делать чем угодно. Выравнивание нужно делать пробелами. Правда, настроить редактор, чтобы он разделял эти два понятия, обычно непросто.
leMar как раз об этом и говорил. Только в положительном ключе: у него и его коллеги код с табуляцией выглядит по‐разному, так, как им обоим больше нравится.
А на «общие» руководства по стилю написания можно забить, используя свои. Их тоже не боги писали. Надо только принять во внимание, что в открытом проекте так можно отпугнуть часть разработчиков.
Что в его любимом редакторе/IDE должна быть возможность автоматической установки отступов. Или хотя бы поиск и замена в выделенном тексте. Проблема, о которой вы говорите, решается и очень легко, по крайней мере в Vim.
По поводу версии Python: для разработчиков очень удобна возможность поставить какой‐то пакет сразу для всех версий Python, присутствующих в системе. Просто укажите в /etc/portage/make.conf нужные вам PYTHON_TARGETS (и USE_PYTHON для старых пакетов). Это удобно, если вы занимаетесь тестированием своих проектов на Python в разных окружениях.
Это относится не к eselect, а к пакетам, использующим python[-r1].eclass.
&&и||слабо различимы, требуя более пристального внимания и затрудняя понимание логики при разборе пачки схожих условий.То, что данное предупреждение добавили в C, говорит о том, что ошибки, завязанные на непонимании приоритета, слишком часты. Я сильно сомневаюсь, что отсутствие предупреждения могло сделать их более редкими. Отсутствие предупреждения также не могло сделать
&&и||более различимыми.Предупреждение, выдаваемое компиляторами, C имеет свои причины. То, что вы пишете не на C, не означает, что в JavaScript эти причины каким‐то магическим образом прекратили своё существование: синтаксис языков при записи комбинаций условных выражений достаточно схож, несмотря на множественные различия вроде результата выполнения
&&/||.Если компилировать как C++ (я помню, что EuroElessar сказал «Если уж говорить про Си») будут тоже две, но ошибки:На этот раз gcc не молчит даже без -Wall.
bcache HOWTOутверждается, что как местом расположения кэша, так и местом расположения HDD может быть любое блочное устройство. Любое — это значит, что вы можете поставить там RAID0 из SSD, LVM раздел или даже другую пару устройств под управлением bcache (хотя это и не имеет смысла).Другой вопрос, что именно надо поставить, чтобы уменьшить время доступа (в интернете утверждают, что кэшировать на RAID0 из SSD не имеет смысла, так как это увеличит задержки; не знаю, насколько можно им верить). Но тот же LVM может склеивать диски последовательно ⇒ не увеличивая время доступа. Хотя, конечно, если бы данные по дискам раскидывал сам bcache, то можно было бы оптимизировать алгоритм.
-wвgit help annotate. Bazaar не получил этого умения после пересмотраbzr help annotate. Subversion умеет через--extension. Хочется поставить себе минус.hg help annotate? Другой вопрос, что их нельзя использовать вместе с языками, где важны отступы. И такой возможности нет в git, bazaar и svn. И наверняка почти во всех остальных VCS. Против изменений «скобочек» эти ключи также не помогут.Так что идея в целом плохая. Но история, тем не менее, в Mercurial «потеряется» не фатально.
Я не вижу, как табуляция сделает код единообразным. Я также не вижу, как пробелы сделают его таким. Convention’ы единообразным код сделают, что бы вы в них не написали про отступы.
Если вы про то, что в разных редакторах отступы будут занимать одинаковое место, то в этом я не вижу совершенно никакого смысла. Код в разных редакторах всё равно будет выглядеть по‐разному; и даже в одном редакторе при разных настройках. Почему бы тогда не написать, что код надо смотреть только в {какой‐то редактор} версии {какая‐то версия} с шрифтом {какой‐то моноширинный шрифт} и начертанием {какое‐то начертание} размера {какой‐то размер} и цветовой схемой {какая‐то цветовая схема} и настройками {какие‐то другие настройки редактора, влияющие на отображение}? Тогда код будет выглядеть единообразно. Если вас не пошлют.
Ничего хорошего в том, чтобы код выглядел в разных проектах одинаково, я не вижу. Человечество выживает за счёт разнообразия, а не за счёт единственности. Единственное но: если вы используете не тот стиль именования, что принят в некотором языке, то код в проекте будет выглядеть неоднородным за счёт внешних библиотек. А скобки, отступы, длина строк, способ разбиения длинных строк и тому подобное можно иметь какими угодно.
А на «общие» руководства по стилю написания можно забить, используя свои. Их тоже не боги писали. Надо только принять во внимание, что в открытом проекте так можно отпугнуть часть разработчиков.
Это относится не к eselect, а к пакетам, использующим python[-r1].eclass.