Стилистические Войны программистов
Подробнее
if( ехрг ) if(ехрг) if ( ехрг ) if (ехрг) Tinaxoox
int fuñe() { //... } int fuñe(){ //... } & Dansken
Dog* dog; Dog * dog; Dog *dog; É V \ ОзпЛ«п
Han maní; Han man2; Supe rilan man3; Han maní, man2, man3 Dansken
class HyClass { public: HyClass(); //.. • protected: //... private: int a; //... }; class HyClass private: int a; protected: public: HyClass(); //... }; Dansken
const char * string; const int * source; const char * str; const int * src; Ges
class Class : public Classl , public Class2 , public Class3 { U ... Y> class Class : public Classl, public Class2, public Class3 { u ... class Class : public Classl, public Class2, public Class3 { H ... }; Tinaxnox
Tinaywx
if( ехрг ) if(ехрг) i к Tinayiox
int fuñe() { //... } int fuñe(){ //... } Tinaxnox
программирование,программист,it,стиль,С++
Еще на тему
просто у каждого разной степени упоротости предпочтения
Принесите мне ментоловый огнетушитель, пожалуйста? А то у меня и дом кривой, и джинсы обтягивающие с подворотами, и куча мужиков в одной кроватиT_T
if (some) - пробел после if нужен во имя отличия ключевых слов от вызовов функций. После имени функции в вызове пробел не ставится.
some *x - в С++, звездочка обязана стоять рядом с переменной, потому что хоть и не очевидно, но именно переменная становится указателем. Пример:
some *x, *y - все верно
some* x, y - теперь у нас x указатель, а y просто тип some, получилась хуета.
а насчёт указателей - тут уже кому как, для одних переменная указатель, для других это переменная указательного типа.
int func{
//...
}
несколько предвзятое отношение?
Есть покруче тема для холивара - таб или пробелы, а если пробелы, то 4 или 8.
spaces: 4
и радует )
Java - тормозная машина, полноценно работать на ней можно на компе с i7, fullhd моником (она очень многословная, просто ПИЗДЕЦ как). Поэтому там и сложилась традиция переносить скобку на новую строку, ну а чо - мониторы у всех збс.
То же самое пошло и в Си\С++.
Javascript - эра верстальщиков, front-end парней с хромобуками и нетбуками. Мало место на экране, сложилось популярное течение ставить скобки на той же строке.
Мой пример с бутером был о другом.
А на счет приватных полей - их конечно обязательно надо последними писать. Причина проста - когда другой разработчик открывает ваш класс, он ожидает по публичным полям и методам примерно понять схему работы этого класса. Поэтому в самом верху класса и должны идти все публичные поля и методы. Приватные - последними, а реализация функций вообще уносится в другой файл.
private
public
protected
?
public просто должен идти первым, а protected вторым. Только из за этого, чтобы открыли файл и сразу читали public и protected поля, а что там внизу файла - пофик.
Большая часть разработчиков на С\С++ использует sublime\vim\emacs без рюшечек, и они привыкли читать интерфейс класса по файлу.
про сильно махровые времена врать не стану - не помню
чаще договориться не смогли и сделали как в армии: пусть безобразно, зато единообразно
даже гугл так сделал
Не помню в какой книге дают совет: если будете обсуждать как делать отступы и где оставлять скобки, то никогда не сможете начать разработку.
if (some === 0 &&
some2 === 1) {
// так нельзя, сливается
}
if (some === 0 &&
some2 === 1)
{
// Бля, теперь у нас два стиля кодирования, ну как-так то, бля, ну как так
}
if (some === 0 &&
some2 ===1) {
// Мы просто поставим пустую строку, чтобы не сливалось.
}
У меня на JS автоформаттер настроен на строго скобку на линию, поэтому я ставлю пустую строку.
Ваш вариант в студию!
var someCondition = ...
if(someCondition) {
someAction()
}
ну и вообще, что там в конце этого длинного ифа, важно не всегда. когда вчитываться будешь - тогда и проскроллишь, ничо страшного. сразу важнее охватить структуру кода взглядом, что ведет к большему приоритету компактности по высоте и единообразию - тогда охватить проще
прост тут someAction - это некий placeholder имелся в виду
boolean check2 = condition2:
boolean check3 = condition3;
if ( check1 && check2 && check3 ) {
//some action here...
}
хз, почему тебя заминусили
реактор ¯\_(ツ)_/¯
переменная boolean занимает 8 бит
а браузер жрет из за кеширования.
А если функция большая, то из-за нехватки регистров еще добавиться и обмен с внешней памятью и тут уже время выполнения увеличится на десятки тактов.
сравнение if else обрабатываются задолго до того как начинают быть нужными, а потом только вставляются в нужный участок время-исполнения.
ну вобще это может зависеть от уставок компилятора
Иначе это голословный пиздёшь.
даже в js щас повсеместно jit
К JS имею отношение посредственное. Но, по моему, существование jit не оправдывает говнокода.
Да вы, батенька, небось и функции вручную инлайните, чтоб говнокода не было?
Вот не надо заветы микроконтроллерщиков тянуть в остальной мир.
Нормальный компилятор под популярную платформу сейчас творит чудеса и выкомпилит он эти лишние переменные из кода ко всем чертям. Особенно, если они использовались только в одном месте.
и планировщик процессора перетасовывает оптимальным образом микрокод на конвеере (не машинные команды, а более низкоуровневая вещь).
Например: (x != null && size(x) > 0) и xIsNotEmpty
some2 ==1) {
// Мы просто поставим чуть более одного пробела, чтобы не сливалось.
}
WYSIWYG-редактор сожрал наши пробелы.
....some2 === 1) {
// вместо точек пробелы и или таб(парсер реактора сьедает пробелы)
//так можно и не сливается
}
не съедает.
у меня сьел. вот тут второй раз
some === 0 &&
some2 === 1 &&
some3 === 2
) {
//Проблемы?
}
одна строка после иф без скобок явно говорит о простоте описываемой конструкции
if(arg == null) return; // зачем тут что-то еще?
скобки вызовут недоумение: кто-то хотел туда что-то дописать и забыл? кто-то оттуда что-то удалил, но забыл скобки? кто-то что-то криво намержил? кто-то начитался про "правильные" кодстайлы?
//просто return, нихуя больше
return;
}
А тем более однострочное условие, когда return не всегда и заметишь на первый взгляд.
"Если вот такая маленькая фигня, return 0"
"Если ещё другая фигнюшка, return 1"
"Ну а когда вот такой поворот, return 2"
"Теперь все частные случаи перебрали и перейдём к самой сути"
Записывать результат в отдельную переменную, которая меняется внутри функции и возвращается в конце - запутывать читателя.
Создавать вложенность if(x) { return y; } else { весь остальной код } - тоже не очень.
Но если говорить про методы - "фигня1,2,3, а теперь давай к сути", то метод не охватывается взглядом и можно не заметить return, который изменяет ход выполнения. Для таких случаев рулит принцип модульности "один вход, один выход".
Присваивание переменной-аккумулятору результата (своего рода return, только не return) - нет.
И от увеличения вложенности только глаза разбегаются. Только сворачивание кусков кода в IDE/редакторе может оправдать такой подход.
Вот внезапный return где-то в глубине блоков - это да, можно не заметить.
Но все эти неохватываемые взглядом методы наверно уже проще разбить на несколько штук.
А пригорание от множественных return у меня как раз от сопровождения кода с большими простынями методов. А отрефакторить такие методы не всегда удается по разным причинам от "мегасрочная правка" до "метод настолько охренительно сложно-связано-составлен и содержит статические зависимости, что разбить его без unit-тестов опасно, а покрыть тестами - невозможно".
Ну тогда удачи и интересных проектов!
Так что и тебе удачи и не встречать всех этих багов! А, да, и не кодить в vim c чужой машины или телефона, потому что "срочнопиздецвсемухана".
В начале функции проверяются (по очереди, не вложенно), как можно больше условий, в которых можно тупо сделать return. А уже потом, ниже в теле функции пойдет смак реализации, какие-то вычисления.
В некоторых случаях множественный return уместен. И я пишу его там, где он уместен.
Но! Любое ветвление, цикл, или простихоспади рекурсия, усложняют код. Разумеется без условных операторов и циклов вменяемое и читабельное приложение не построить. Однако если есть возможность уменьшить нелинейность кода без ущерба читабельности, стоит это сделать.
Как по мне, на первом месте (после функциональности конечно) читабельность, второе - производительность. А уж потом все остальное.
Спасибо! Всем программистам удачи!
и вообще не надо пытаться угадывать код, его надо читать. хотя бы раз прочитать, не понял - тогда это, возможно, говнокод. ну или ты просто устал. многие начинают ругать код едва взглянув. и вот прочитать код и не заметить аж целый ретурн, который даже цветом выделен - это как-то странно
и то тогда это был не недосмотр просто при написании, это был косяк при мерже
и ради этого надо писать более громоздкие конструкции? ну хз
я думаю, скорее нет
во все языки, где эти скобки опциональны, эту фичу продолжают добавлять из раза в раз, из языка в язык. и никто ее не выкинул, потому что она такая капец error-prone. значит она не такая уж и error-prone
тут уж никакой обратной совместимостью не пахнет
Во вторых, фича с методами немного не про то. В JavaScript ES6 к примеру также можно опускать скобки:
const fn = some => Math.sin(some); // не только без скобок, но и return опускаем, ничего не обычного.
ecma это была тема по стандартизации js, до того был сам js, который испытал влияние явы, которая задолго до того позаимствовала почти весь синтаксис из сишки/плюсов, где эта фича испокон веков
я б вот совершенно не сказал, что какие-то современные языки испытывают влияние ecma, потому что там своего-то ничего не придумали
есть два больших полюса влияния - сишка и ml - и в обоих лишний синтаксический шум старались обязательным не делать
вот например наркоманскую кучу способов описывать типы сишки в D уже упорядочили и упростили, мешала. а эту не стали
я вот тож не считаю, что она в чем-то провинилась настолько, чтоб ее выпиливать
class MyClass
{
int a;
public:
int b;
};
эквивалентна
class MyClass
{
private:
int a;
public:
int b;
};
Да и вообще есть несколько разных распространённых вариантов, которые не вошли в картинки.
кончишьусовершенствуешься после прочтения.Нужно знать правило.
После struct - по умолчанию public, после class - private.
Для примера: бухгалтер имеет цель содержать счета в секрете, но для налоговой важен доступ к счетам. Примерно так.
алсо широкие моники позволяют не думать о компактности вширь
тогда я скажу, чтоб шли на хуй, мне нужны условия для работы ну или время себе их обеспечить
Edit your ~/.nanorc file (or create it) and add:
set tabsize 4
set tabstospaces
4 ничо, 8 на широком монике - еще лучше
поэтому и лучше не прибивать гвоздями пробелов, а юзать настраиваемые табы
Опять же, используемые только для отступов табы легко парой движений заменить на пробелы.
Примеры:
Доступ владельца сайта к исходному коду стилей в wordpress из админки, ага, попробуйте там пожить с табуляциями.
Онлайн репозитории, github, bitbucket, etc.
табы int x = 1,
табы пробелы y = 2; // y строго под x для любого размера таба
Поэтому, легче использовать пробелы, чем учить всех программистов правильно использовать табы.
Проблема в удобстве и автоматизации. Работа с пробелами успешно автоматизирована. Жмём таб - добавляется N пробелов и т.д. С табами автоматика глючит и скорее всего заменит отбивку до нужной ширины пробелами на табы, из-за чего всё будет разъезжаться с другим размером табов.
Пробелы автоматизированы, с пробелами не надо думать над СУКА МАТЬ ИХ НЕВИДИМЫМИ СИМВОЛАМИ, и можно писать код.
Как будто программисту не о чем подумать, кроме о том, как правильно поставить в коде таб. Это просто отвлекает от сути. Так почему бы не убрать эту хрень и пересесть всем на пробелы?
> не надо думать
хм...
пойду-ка я проверю, работает ли мой биореактор
Программисту надо думать над решением задачи. Человек не может всё удержать в голове. Если программист отвлекается на пробелы, он рискует упустить что-то важное.
Поэтому у нас подсветка синтаксиса, подсказки сигнатур функций, кнопка "автоформат" и т.д. Всё для того, чтобы программист не отвлекался на маловажную хрень, которая не связана с решением задачи.
только настройка меняется
и оно вам явным образом ставит таб, всё просто и явно, что ткнул - то и получил. и это будет работать даже в самом убогом редакторе, который не знает про эти трансформации таба в пробелы, тупо ставит таб.
Но если исключить такие места из программы и не пытаться выравнивать столбцы, то табы станут простыми и понятными.
ломать глаза об 1-2 пробела мне тож неохота, я тогда сильно менее продуктивен
Это вроде как одно из первых требований к отображению кода - он должен отображаться всегда одинаково.
использую sublime text, а под word wrap имелось в виду его поведение как в обычном блокноте
>мне даже странно слышать, что он кому-то из программистов нужен
большие sql-запросы должны быть видны на экране, а не убегать за его пределы. Их не всегда имеет смысл принудительно разбивать на строки энтером
Не говоря уж о том, что я работал с языком, где семантика кода в строку и кода с новой строки разная.
В частности, у меня в команде попался товарищ, у которого в редакторе не только стояло отображение табуляции в 6 символов вместо 4х по всех команде, но и автозамена табуляции на пробелы, из-за чего он просто стал портить весь код, который правил.
чота все продолжают утверждать, что табы куда-то разъезжаются
чота у меня ничо никуда не разъезжается никогда
разве что эти люди пытаются юзать табы для чего-то кроме индентейшна - но это реально изврат :)
автозамена на пробелы - этот изврат придуман для любителей пробелов, это атавизм. жмакать таб удобнее, но нет, мы хотим пробелы, но не хотим их отстукивать!
были б у вас табы, чувак выставил бы длину таба хоть 6, хоть 7, и всё было бы норм у всех. на разных мониках, в разном софте - всё отлично настраивается
вот у меня, например, везде 4, кроме дифалки. в дифалке удобнее 8. потому что мне там важнее структуру видеть, чем чтоб в экран влезало.
а вот Re-l вроде программист
Итого: такие шутки и вопросы возникают только у грязных кодообезьян, а судя по "правильному" положению фигурной скобки ещё и сидящих на игле мелкософта