Перейти к содержанию

Кто какой стиль кодинга предпочитает?


Какой стиль кодинга предпочитаете?  

94 пользователя проголосовало

  1. 1. Какой стиль кодинга предпочитаете?

    • Краткий код
      19
    • Достаточно понятный для меня
      44
    • Понятный для всех
      12
    • Максимально откомментированный и понятный
      19


Рекомендуемые сообщения

Например, как принято в перле - максимально краткий, но очень сложный для разбора другим людям(да впрочем и самому себе спустя некоторое время) - это элегантно),

или как можно более понятно (множество комментариев, система отступов и меток),

или просто быстро?

зы. имеются ввиду достаточно большой кодинг, а не 15 строчек в шеллскрипте :)

Ссылка на комментарий

хах, не поверите, но уже 3й раз заново начинаю писать движок на php :)

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

Ссылка на комментарий

Я стараюсь для всего насоздавать классов и методов донельзя кратких, чтобы потом код состоял просто из этих вызовов, но блин когда приходится существенно менять код уже никакие перегрузки не помогают, и приходится разбирать и менять один за другим все подряд... И ведь не лень иногда 10 строчек дожать до двух :) (правда так сильно сжать получается только перл :) )

Ссылка на комментарий

Стараюсь комментировать все что могу, потому как ни в чужом ни в своем старом коде разобраться для меня просто нереально. Иногда впрочем забываюсь и пишу как бог на душу положит (потом долго ругаюсь). Не сжимаю никогда почти, разве только если от этого код станет понятнее.

Когда код предполагает быть более 1500-2000 строк, стараюсь запихнуть его в классы, но зачастую не сортирую то что написал и в результате методы разных классов идут вперемешку.

В случае в классами обожаю когда основной код состоит из 1-2 строк, собственно создаем класс и вызываем метод :-D . В названии класса использую кучу подчеркиваний, так что оно иногда превращается в целое предложение.

И еще одна деталь: всегда стараюсь чтобы открывающая и закрывающая инструкции группы команд стояли на одной вертикали, а внутренние инструкции были сдвинуты, то есть, вот так:

if(<нечто>)
{
здесь_сдвиг <делаем что-то>
}

Не люблю когда в чужом коде встречается противоположный вариант:

if(<нечто>){
здесь_сдвиг <делаем что-то>
}

PS Также испытываю личную глубокую ненависть к оператору switch .. case, в том варианте, в каком он существует в С-подобных языках.

Ссылка на комментарий

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

В именовании переменных предпочитаю так называемый верблюжий стиль:

int valueOne, valueTwo

А в расстановке скобок предпочитаю нелюбимый Dik'ом стиль:

void function(int somePar, anotherPar) {
...
}

P.S. Интересная тема, очень интересно читать предпочитания местных программистов.

Ссылка на комментарий
И еще одна деталь: всегда стараюсь чтобы открывающая и закрывающая инструкции группы команд стояли на одной вертикали, а внутренние инструкции были сдвинуты, то есть, вот так:

+1, полностью согласен, так удобнее видеть открывающие и закрывающие скобки

В назкании класса использую кучу подчеркивание, так что оно иногда превращается в целое предлложение.

С широкоформатными мониторами стало гораздо удобнее, когда куча сдвигов да еще и названия длиннющие :)

тем не менее вызывая многопараметровые функции приходится часто делать вроде такого:


a=some_function(
parameter1,
blablabla(lalala,lalala2),
parameter3,
parameter4
);

Ссылка на комментарий
+1, полностью согласен, так удобнее видеть открывающие и закрывающие скобки

Вроде не испытаваю сильных проблем, вижу что и откуда. Да и если что непонятно, то использую подцветку скобок :).

Ссылка на комментарий

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

Ссылка на комментарий

Chaos

Главное запомнить теперь название самой функции полностью и правильно. ))

Скобки предпочтаю ставить так, как Dick не любит.

Такое тоже часто приходится городить:

a=some_function(
parameter1,
blablabla(lalala,lalala2),
parameter3,
parameter4
);

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

часто пользуюсь оператором ?:

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

Ссылка на комментарий

Предпочитаю писать в т.н. стиле Кернигана-Ричи



class Point {
public:
Point(double xc, double yc) :
x(xc), y(yc) {
}
double distance(const Point& other) const;

double x;
double y;
};

double Point::distance(const Point& other) const {
double dx = x - other.x;
double dy = y - other.y;
return sqrt(dx * dx + dy * dy);
}
#include 

Для переменных класса ставлю префикс вроде m_*** или просто _, для параметров функций - "a". Однако не всегда).

По поводу именования переменных/функций/классов

Если пишу на Java или с использованием библиотеки Qt - то стиль, являющийся небольшой вариацией C++ Programming Style

В остальных случаях придерживаюсь стилю аля STL/Boost

Ссылка на комментарий

Программирую на ассемблере. Стиль:

1. Обобщенное словесное описание решения задачи (буквально в нескольких предложениях)

2. Создание блок-схемы (хотя многие этим пренебрегают). Без нее сложновато на таком языке писать.

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

4. При написании выполняю отладку каждого написанного фрагмента (отлаживать прогу целиком потом будет гораздо легче)

Основные фрагменты, которые могут пригодиться в будущем, сохраняю отдельно.

В основном количество строк в моих программах колеблется в пределах 1000-1500.

Ссылка на комментарий
  • 1 месяц спустя...

стараюсь писать самодокументированный код с комментариями и шириной в 80 символов.

что-то типо:


/**
* Модуль для работы с системными службами
* License: GPLv2
* Authors: Дамбаев Алесандр, [email protected]
* Copyrights: Дамбаев Александр, [email protected]
* Date: Jul 26, 2009
* Version: 1.0
* Example:
* ---
* import prt_ctrl. scm;
* Scm scm = new Scm;
* Service svc = scm. open_service( "Prt_Service");
* try
* {
* svc. stop( );
* }catch( Exception e)
* {
* //kills svc
* }
* ---
*/
module prt_ctrl. scm;

import win32. windows;
import win32. winsvc;
import std.stdio;
import std.path;
import std.c.string;

// права доступа к службе
const SERVICE_RIGHTS = SERVICE_START | SERVICE_STOP | SERVICE_QUERY_STATUS |
SERVICE_QUERY_CONFIG;
// права доступа к менеджеру служб
const SC_RIGHTS = SC_MANAGER_ALL_ACCESS;

/**
* класс, описывающий системную службу
*/
class Service
{
public:
/**
* конструктор класса
* Params:
* scm = дескриптор менеджера служб
* name = внутреннее имя системной службы
* dw_access = права доступа к системной службе
* Throws:
* "unable to open service" если не удалось получить
* требуемый доступ к службе.
*/
this( SC_HANDLE scm,
char[] name,
DWORD dw_access = SERVICE_RIGHTS)
{
h_service = OpenService( scm, (name~'\0'). ptr, dw_access);
if( !h_service)
throw new Exception( "unable to open service");
}
~this( )
{
if( h_service)
CloseServiceHandle( h_service);
}
/**
* запуск системной службы
* Throws:
* "unable to start service" если запуск не удался;
*/
void
start( )
{
if( !StartService( h_service, 0, null))
throw new Exception( "unable to start service");
}
/**
* останавливает службы
* Throws:
* "unable to stop service", если не удалось дать команду
* для остановки, либо служба не остановилась
* "unable to query service status", если не удалось
* узнать статус службы
* "service stopping is timouted", если служба не смогла
* остановиться за 60 сек.
* "unable to query service config", если не удалось
* узнать конфигурацию службы
*/
void
stop( )
{
SERVICE_STATUS ss;
if( !ControlService( h_service, SERVICE_CONTROL_STOP, &ss))
{
throw new Exception( "unable to stop service");
}
if( !QueryServiceStatus( h_service, &ss))
throw new Exception( "unable to query service "
"status");
uint wait;
while( ss. dwCurrentState != SERVICE_STOP_PENDING &&
wait < 6000)
{
Sleep( 10);
++wait;
if( !QueryServiceStatus( h_service, &ss))
throw new Exception( "unable to query "
"service status");
}
if( ss. dwCurrentState != SERVICE_STOP_PENDING)
throw new Exception( "service stopping is time"
"outed");
wait = 0;
while( ss. dwCurrentState != SERVICE_STOPPED &&
wait < 6000)
{
Sleep( 10);
++wait;
if( !QueryServiceStatus( h_service, &ss))
throw new Exception( "unable to query "
"service status");
}
if( !QueryServiceStatus( h_service, &ss))
throw new Exception( "unable to query service "
"status");
if( ss. dwCurrentState != SERVICE_STOPPED)
throw new Exception( "unable to stop service");
}
/**
* Возвращает имя бинарного файла системной службы
* Returns:
* имя бинарного файла системной службы
* Throws:
* "need to open service first", если доступ к службе
* не получен
* "unable to query service's config", если невозможно
* получить конфигурацию службы
*/
char[]
image( )
{
QUERY_SERVICE_CONFIG * service_conf;
DWORD dw_needed;
char[] buf = new char[ 256];
service_conf = cast(QUERY_SERVICE_CONFIG*)buf.ptr;
if( !h_service)
throw new Exception( "need to open service "
"first");
if( !QueryServiceConfig( h_service, service_conf, 256,
&dw_needed))
throw new Exception( "unable to query service's"
" config ");
return getBaseName( service_conf. lpBinaryPathName[ 0..
strlen(service_conf. lpBinaryPathName)]);
}
private:
/// дескриптор службы
SC_HANDLE h_service;
/// имя службы
//char[] s_name;
}

/**
* класс, описывающий работу с менеджером служб
*/
class Scm
{
public:
/**
* Конструктор класса
* Params:
* s_mach = имя компьютера
* dw_access = права доступа к менеджеру служб
* Throws:
* "unable to open sc", если невозможно получить доступ с
* затребованными правами
*/
this( char[] s_mach = null, DWORD dw_access = SC_RIGHTS)
{
s_machine = s_mach;
if( s_mach != null)
h_sc = OpenSCManager( (s_machine~'\0'). ptr,
null, dw_access);
else
h_sc = OpenSCManager( null, null, dw_access);
if( h_sc == null)
throw new Exception( "unable to open sc");
}
~this( )
{
if( h_sc)
CloseServiceHandle( h_sc);
}
/**
* Создает класс службы и открывает ее
* Params:
* name = внутреннее имя службы
* dw_access = access flags
* Returns:
* указатель на экземпляр класса Service
*/
Service
open_service( char[] name, DWORD dw_access =
SERVICE_RIGHTS)
{
return new Service( h_sc, name, dw_access);
}
private:
/// имя компьютера
char[] s_machine;
/// дескриптор менеджера служб
SC_HANDLE h_sc = null;
}

вот вопрос - комментарии на каком языке предпочитаете писать? Раньше все комментарии оставлял на английском, с замахом на глобальность творения (:, но после того, как начал работать "программистом", заметил, что довольно много людей не знают английского... кто-нить читал каменты к коду на транслите? (: приходилось ... гг

А вобще - стиль склонен меняться с опытом

Ссылка на комментарий
всегда стараюсь чтобы открывающая и закрывающая инструкции группы команд стояли на одной вертикали, а внутренние инструкции были сдвинуты

Аналогично. Хотя раньше мог и так извращаться:

if($var==true) { echo 'true'; } else { echo 'false'; }

вот вопрос - комментарии на каком языке предпочитаете писать?

У меня всё вперемешку (если имеются). Никак не могу себя заставить писать их в достаточном количестве.

Ссылка на комментарий

The_Ice, только на английском :) т.к. переключать раскладку на русский лень :)

А за такое подробное комментирование респект, не могу я столько комментов писать - лениво :)

if($var==true) { echo 'true'; } else { echo 'false'; }

опять же из-за лени в таких случаях пишу просто:


print $var?"true":"false";

даже несмотря на то, что часто потом приходится вместо простой вставки доп-го кода изменять существующий.

Ссылка на комментарий
print $var?"true":"false";

это синтаксический сахар, собственно для таких целей и введен. лучше чем if ... в данном случае.

поверите

=) как не странно, верю.

но уже 3й раз заново начинаю писать движок

карандаш, бумагу и ..... никто не отменял.

самодокументируемый код - наш метод.

а если можно вставлять описание, а потом из листинга генерить хелпарь, пишется так то бы потом "лоб" не морщить.

Ссылка на комментарий

Грамотное программирование кто-нибудь применяет на регулярной основе? ( http://ru.wikipedia.org/wiki/%D0%93%D1%80%D0%B0%D0%BC%D0%BE%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 )

Ссылка на комментарий

Однако документирвать код по русски ИМХО должны лишь 1Совцы, ибо на нем и пишуть. А для программиста незнание английского (как "письменного" так и "читательного") сродни затворничеству, отключению от бОльшего числа источников знаний. Сколько раз слышимо было, в ответ на указание на книгу/статью/хелп: "Там же всё на английском! ...". Так и будем варится в собственном соку? бррр.

Сам комментов не пишу, потому как программ более 200строк не писал более года. Хотя заголовок, подобыный The_Ice ставлю.

Вообще хорошенько пререосмыслить кодинг мне очень помогла книга

Стива Макконнелла - Совершенный Код, прочел 2жды.

Ссылка на комментарий
Однако документирвать код по русски ИМХО должны лишь 1Совцы, ибо на нем и пишуть. А для программиста незнание английского (как "письменного" так и "читательного") сродни затворничеству, отключению от бОльшего числа источников знаний. Сколько раз слышимо было, в ответ на указание на книгу/статью/хелп: "Там же всё на английском! ...". Так и будем варится в собственном соку? бррр.

С этим я согласен, однако, нет уверенности в том, что тот, кто будет работать после меня будет знать технический английский, и, чтобы лишний раз меня не дергали - приходится писать на доступном языке :)

Сам комментов не пишу, потому как программ более 200строк не писал более года.

вот тут опять двояко: а если этот код, в перспективе, окажется частью большого проекта? Будет ли время/желание вспоминать что он делает и каментить его? Было время, когда писал движок для игры. Я бы не сказал, что это был большой проект, но было интересно. Потом, внезапно, подкрался диплом, и его пришлось забросить. После диплома, где-то месяца пинания балды, появилось желание продолжить разработку движка, но, пытаясь влиться в работу снова, я с ужасом осознал, что существующая скудная документация (а точнее - практически полное её отсуствие), не позволяют вспомнить то, что должно было бы получиться в итоге. Энтузиазм иссяк, хотя интерес остался... После этого стараюсь не экономить время на документирование...

И вобще: распространено мнение, что нужно добиваться повторного использования кода для экономии времени/средств. Но, есть вполне авторитетные личности, которые утверждают, что лучше заново переписать код с учетом конкретной задачи, чем подгонять под нее уже существующий код. Кто что думает по этому поводу?

Оглядываясь назад, вспоминаю как часто изобретал велосипеды снова и снова переписывая классы строк, динамических массивов (элементы которого должны были обладать полиморфизмом), библиотеку для работы с сетью и т.п. И каждая новая версия включала в себя реализацию нового опыта - это плюс, но столько времени уходило на написание и отладку... В итоге, я просто перешел с С++ на D, в котором это уже есть с тем функционалом, который меня устраивает. И теперь больше склоняюсь к тому, что лучше своеобразная смесь: взять старый код и переделать его под конкретные нужды...

Ссылка на комментарий
с С++ на D

+1

Это раньше нуно было делать прогу маленькой и бысторой, счас мощности позволяют)))

От себя скажу, кодинг это сродни творчеству, бывает и Пушкин, а бывают и собрания сочинений Васи Пупкина...

ттак вот чем мы сейчас занимаемся это Вася пупкин) не в обиду...

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

Я- вор ))))

Добавлено спустя 1 минуту 21 секунду:

да забыл... главное работает!!!!

Ссылка на комментарий
ттак вот чем мы сейчас занимаемся это Вася пупкин) не в обиду...

никто и не утверждал обратного) поэтому и топик про кодинг, а не программирование (:

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

...

главное работает!!!!

ну, все зависит от того что считаешь важным в том деле, которым занимаешься: для кого то главное - результат, для кого то - процесс...

Ссылка на комментарий

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...