Underscore VS CamelCase

2.

4.:

/*
 * Расчет толстоты
 */
int trololo; // Уровень троллизма

>Нижний слэш

Слеш бывает прямым и обратным: /, \. Нижнего слеша не бывает.

заглавные буквы

int MoveSuperCar;

Это называется upper CamelCase, вообще-то.

4. Дефис.

4. Все варианты негодные.

Я, как поклонник питона, голосую за первый вариант для имен классов и второй для остального.

(defvar move-super-car 42 «Description»)

Плюсую.

Дефис

Это же знак «минус»?..

> 4. Дефис.
Лиспер штоле?

Угу.

>Расчет толстоты

///KILLING SPREE
Eddy_Em->DragToHell (true);
cout << "Nice work!" << endl;[[/code]][/i]

>> Лиспер штоле?

Тролль. Нет, мне просто нравится такой стиль. Применяю только в шелл-скриптах.

Нравится 2-ой стиль, но приходится пользоваться 1-ым.

Неправильно пишешь, надо так:

/*
 * Любимец публики отправляется на отдых в теплые страны (на время отпуска)
 */

the_body *who = get_body("Eddy_Em"); // Выбираем отпускника
drag_to_hell(who, 30, "days");       // И отправляем на месяц погреться
printf("I'll be back!\n");           // :)

Прочти первую главу Кернигана и Пайка «Практика программирования», и эти (и некоторые другие) вопросы будут для тебя решены.

)

код возврата не проверил, может недостаточно места в аду. и что означает true?

Небольшая поправка:

printf("I need a vacation!\n");   // А персонаж тот же  :)

Патч принят: drop быстрее работает :)

ИмяКласса имя_метода имя_переменной

/** а док-комментарий нужно писать там, где его распознает инструмент */

2. 2.
Так приучили, да и мне кажеться наиболее практичным.

Если код пишется и читается с участием подсветки синтаксиса, то особой разницы между 1 и 2 нет.
По идентификаторам: в 3 варианте, имхо, каша.
По комментариям: главное — не увлекаться чрезмерно такими забористыми разделителями. Им место только где-нибудь в шапке. А в остальном коде лучше уж пустыми строками разбавить.

Самое сложное, на мой взгляд, это придерживаться одинакового стиля во всём проекте :)

>Нижний слэш
Лимбо слэш FIXED.

>Самое сложное, на мой взгляд, это придерживаться одинакового стиля во всём проекте :)

Согласен.

MyClass class;
MyClass *another_class;
class.method_1();
another_class->method_2();

...
void MyClass::method_1()
{
     int i = 0;
     double d = 0.;
     std::string s;
     i = (_class_some_property++) + d;
     return;
}

как то так. коментарии нигде не пишу. называю переменные и ф-и по их действию. Например:

MainWidget::show_about_window()
MainWidget::quit_app()
Device::do_connect()
Device::do_disconnect()
Data::do_save()
Data::is_altered()
Data::do_load()

camelCase, в QtCreator есть удобное дополнение по начальным буквам слов.

например QPuB<Tab> QPushButton, QLEd - QLineEdit, QChBo - QCheckBox

camel case с маленькой буквы

moveSuperCar в интерфейсах, move_super_car внутрях и move-super-car в лиспах.

CamelCase для Java/JavaScript, underscore для python, html, css. underscore как-то более привычен, т.к. еще со времен васика в школе пошло.

CamelCase vs snake_case vs totaluebancase

Поправил название.

/* уровень троллизма */

Только ANSI C, только хардкор!

Ты сейчас, сам того не желая, стравишь флейм C vs C++.

а вот еще животрепещущий вопрос, кто как ставит пробелы возле звездочек и амперсандов у ссылок/указателей?

1.

void *ptr;

void* ptr;

void * ptr;

>кто как ставит пробелы возле звездочек

Я по третьему варианту ставлю, для меня так более логично.

Хотя если влезаю в код в котором по второму варианту все (такой вариант встречается наиболее часто), продолжаю в том же духе не меняя на свои пристрастия.

1.

Всегда, независимо ни от чего.

1.

ну 1 как бы очень сионистически, но плюсофилы зачастую используют 2, какбы намекая что это такой тип*, а это вот отдельно имя_переменной.

я тут недавно начал писать стопятьсотый нафик никому ненужный скриптовый яп на плюсах :3, по 10 раз на дню переделывал эти ссаные пробелы у *&, решил оставить вариант 1. ладно хоть к отступам в стиле K&R у меня любофь, над этим голову ломать не пришлось

ну 1 как бы очень сионистически

Это чем же?!! О_О Впервые слышу такое любопытное определение.

Я так приучен с первого дня кодинга на С.

но плюсофилы зачастую используют 2, какбы намекая что это такой тип*, а это вот отдельно имя_переменной.

Угу, угу... видел и слышал такие «обоснования».

Вот только столь же часто встречал записи такого рода:

int* pint, pint1, pint2;

авторы которых совершенно искренне считали, что и pint1, и pint2 - это тоже указатели.

Нет уж, как я с самого начала привык к 1, так и буду писать везде.

2 или 3, 3

1

2,3

Раз уж тема зашла о стиле вообще - то как бы вы записали следующее:

1.

int sex;
sex = masha+(saha/vasya);

int sex;
sex = masha + ( saha / vasya );

2.

Но здесь я не настолько категоричен. :)

Иногда приходится писать, как в 1.

Разумный выбор по ситуации/контексту рулит.

underscore — для локальных переменных и экземпляров классов, короче для id, которые будут использоваться в коде.
camelсase — для классов и прочей логики.
Лисперы недоумевают над твоим (в)опросом.

Либо camelCase/CamelCase, либо дефисы (сам их не использую, но смотрится красиво). Подчёркивания некрасивы. Ну про третий вариант я думаю понятно, почему он ужасен.

int sex;
sex = masha + (saha / vasya);

только так

> смотрится красиво
я бы не сказал: йцуйцу_йцуйцу горазде легче читается, чем йцуйцу-йцуйцу
суть в том, что - раз в 5 быстрее набирать, чем _

Лисперы недоумевают над твоим (в)опросом.

А что в нем такого? Напротив я считаю, тема актуальна, и полезна, недооценивать стилистику не стоит, можно накатать так код, что без бутылки водки не разобрать.

Стилистикой многие брезгуют, не знакомясь с ней вовсе, считая неважным элементом, в следствии чего можно встречать полнейший хаос в коде. Такие темы должны подниматься, чтобы хоть как то акцентировать внимание новичков на стилистике как не о последнем деле в программировании.

Ну это всё-таки индивидуальные предпочтения. Меня подчёркивания раздражают и легче не читаются.