LINUX.ORG.RU

Стиль написания кода для разных языков

 , ,


0

0

Я пишу на нескольких языках и стараюсь оформлять код так, как это делали до меня в том же проекте. Раньше, если я сама что-то начинала, то просто следовала питоновским рекомендациям, так как писала все на питоне. Но уже какое-то время я пишу на C++, Java, Vala. И везде есть свой устоявшийся стиль. Честно говоря, устала перепрыгивать с одного на другой. Хотелось бы узнать, как другие решают эту проблему для себя (и решаете ли?). Например, как вы подходите к оформлении названий локальных переменных, глобальных констант, множеств, методов, свойств, классов, отдельных функций? Ставите ли пробел перед скобкой с параметрами функции, начинаете ли новый блок фигурной скобкой с новой строки и такое прочее. Я не питаю особых надежд на то, что мне тут все распишут, но может быть кто-то один найдется :)



Последнее исправление: CYB3R (всего исправлений: 1)

Ответ на: комментарий от Karapuz

То есть, вы советуете следовать этому стилю и во всех остальных языках с похожим синтаксисом? Хорошо, учту :)

Dirty_Diana
() автор топика

Я думаю с опытом вы будет с легкостью будете переключаться с одного стиля на другой. Вообще чем больше изучаешь программирование, тем все более, казалось бы, значимые вещи становятся несущественными. Вначале перестаешь обращать внимание на стиль (т.е. все равно какой, лишь бы глаза не резало), потом туже участь ждет и синтаксис языка, потом и семантика, а потом наступает наивысшая степень - пофиг вообще на языки, главное алгоритмы, предметная область и тп.

dizza ★★★★★
()

> стараюсь оформлять код так, как это делали до меня в том же проекте.

Это _единственно правильный_ способо оформления кода. Никакого другого не существует.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

А надо было дальше прочитать :) Что предлагаете делать, если до меня никак не делали в виду того, что я сама начинаю проект?

Dirty_Diana
() автор топика

Оба упомянутых стиля - и GNU, и Sun, - говно. Только Documentation/CodingStyle рулит.

tailgunner ★★★★★
()
Ответ на: комментарий от Dirty_Diana

А я прочитал.

Если сами начинаете проект, так и выбираете свой любимый стиль кодирования. В чем проблема? :)

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Если сами начинаете проект, так и выбираете свой любимый стиль кодирования. В чем проблема? :)

Проблема в выборе, как обычно ;) Хорошо, когда уже до тебя кто-то выбрал...

const86 ★★★★★
()
Ответ на: комментарий от dizza

> а потом наступает наивысшая степень - пофиг вообще на языки, главное алгоритмы, предметная область и тп.

Угу, map и fold на jmp начинаешь делать. Там, где не надо.

mv ★★★★★
()

Начинал с C#, затем перешёл на C и на C++. Сейчас перешёл на Python.
Сначала, на C#, у всех был один стиль, уж так сложилось тогда, в ранние времена .NET. На сях уже приходилось смотреть на то как сделано было до меня. Если и изменял стиль, то не сильно. В своём коде и проектах сам диктую стиль(гибрид пайтона и C#).
Вообще, меня больше всего устраивает стиль именно пайтона и гугловский стиль для Си/СиПП-специфичных вещей.

tia
()
Ответ на: комментарий от ananas

ИМХО это(отступы перед скобкой после else, while) уже перебор:

For the body of the function, our recommended style looks like this:

     if (x < foo (y, z))
       haha = bar[4] + 5;
     else
       {
         while (z)
           {
             haha += foo (z, z);
             z--;
           }
         return ++x + bar ();
       }

ipc
()

Ну у меня вот так:

  • С, Python: типы - CamelCase, всё остальное - snake_case
  • C++:
    • для себя: всё на snake_case (иногда замечаю за собой что пишу в camelCase, наверно из-за Smalltalk-а)
    • на работе: по требованиям к кодинг стайлу на работе (camelCase)
  • Smalltalk: camelCase
  • Scheme: snake-case

Хотя тут стоит отметить то, что на питоне и схеме я в последнее время пишу ну очень мало. И на С++ для себя - тоже. Поэтому у меня преобладает camelCase и проблем нет =)

yoghurt ★★★★★
()

>Ставите ли пробел перед скобкой с параметрами функции

Нет. Кстати, обычно принято наоборот - пробел ставить перед скобкой после ключевого слова - if (...), а после имени функции - нет. Но я этого общепринятого стиля избегаю :)

начинаете ли новый блок фигурной скобкой с новой строки


Обязательно. Мне лишнюю строку не жалко, зато всегда хорошо видно начала нового блока.

Я не питаю особых надежд на то, что мне тут все распишут


Сейчас тут будет срач и холивор :)

KRoN73 ★★★★★
()
Ответ на: комментарий от yoghurt

Ага. Или хотя бы вот так:

if (x < foo (y, z))
{
    haha = bar[4] + 5;
}
else 
{
    while (z)
    {
        haha += foo (z, z);
        z--;
    }
    return ++x + bar ();
}

P. S. Неиспользование составного оператора - зло. Потом при изменении можно легко внести баг.

ipc
()
Ответ на: комментарий от yoghurt

>Ну у меня вот так

Там, где есть массовые обращения к чужим либам с camelCase (Java в основном) - приходится писать в camelCase. Но крайне не люблю этот стиль. Почти ненавижу :) Где можно - предпочитаю snake_style.

Как уже говорил, после ключевых слов перед скобкой пробел не ставлю, фигурная скобка всегда в начале строки, а парная ей - всегда под ней.

Одиночный оператор фигурными скобками не окружаю.

Длинные списки параметров всегда разбиваю в несколько строк.

Стараюсь, ещё по thinking forth писать как можно более короткие методы. Но нередко опускаюсь и до многостраничных простыней. Хотя никогда не забываю, что это - зло.

При _написании_ кода вынесением общего кода обычно не сильно страдаю. Если один и тот же фрагмент используется в 2-3 местах, то могу оставить копипаст вместо рефакторинга. А вот при редактировании - если мне одинаковые изменения нужны хотя бы в двух местах - рефакторинг обязателен.

В присваиваниях и сравнения оператор окружаю пробелами.

...

Наверняка много ещё чего забыл :)

...

Вот в чём так и не выработал для себя стиля - так это в написании Форт-простыней с условными операторами. До сих пор мучаюсь :)

KRoN73 ★★★★★
()
Ответ на: комментарий от ipc

> Потом при изменении можно легко внести баг.

Ты изменяешь исходники на однострочном телетайпе? Мож всётаки руководство расщедриться на монитор? Хотя бы CGA или EGA, если уж VGA совсем никак.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

>Осталось заменить имена переменных на a0, a1 и т.д.

Будет непонятно

И убрать явно лишние разрывы строк.

Будет неудобно.

staseg ★★★★★
()
Ответ на: комментарий от LamerOk

А вы попробуйте.

При отступах и куче пробелов со всех сторон операторов глаза разбегаются. А так весь код перед глазами. Удобно.

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

staseg ★★★★★
()
Ответ на: комментарий от staseg

>А вы попробуйте.

Тут я за кадром поднял табличку «сарказм».

staseg ★★★★★
()
if (t=='1') {W: {cout<<"1-vvod mass, 2-vivod, 0-v_menu"<<'\n'<<"Vvedite chifru:";}cout << endl;

       {

                cin>>m;

                if(m=='1') {for (int i=0; i<4; i++) 

                   {

                       cout << i << " element mass1: ";

                       cin >> mass1[i];

                       } goto W;}

главное так не пишите

wlan ★★
()
Ответ на: комментарий от anonymous

Вот, да. в сях очень много синтаксического мусора

(if (< x (foo y z))
  (setf haha (+ 5 (aref bar 4)))
  (loop while z
        do (incf haha (foo z z))
           (decf z)
        finally (return (+ (incf x) (bar)))))

Love5an
()
Ответ на: комментарий от Love5an

>Вот, да. в сях очень много синтаксического мусора

Зато язык удобный, быстрый и компактный, не в пример лиспу.

anonymous
()
Ответ на: комментарий от anonymous

>Зато язык удобный
Нет. Особенно, с возрастанием кодобазы, и, особенно, с повышением абстракции. Впрочем, по сравнению с ассемблером, и, может быть, с виртовскими языками - возможно.

быстрый

Современные реализации CL не то чтобы очень уж отстают.

и компактный

«Компактность» это хорошо сказано. Си - язык компактный, но совершенно дико многословный, и эта компактность как раз для того чтобы скрыть последнее и существует.
В противовес тому же CL, который очень лаконичный, и поэтому может позволить себе названия из полноценных слов и предложений.
Вот, рекомендую статью по теме.
http://pozorvlak.livejournal.com/91293.html

Love5an
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.