Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp
Я бы добавил чуточку коммента в код для разъяснения хода Выших мыслей
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp\
неужели ты понимаешь, что там делается после
if(*(WORD*)(vmem)==0x5A4D) {
Re: Стиль написания
От:
Аноним
Дата:
20.09.06 16:47
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp
Здравствуйте, Аноним, Вы писали:
А>звеняйте, но обфускатором не пользовался, да и зачем использовать его для проэкта на cpp, это ведь не .net, который легко декомпилируется.
Я думаю для вас хотели донести простую мысль,
что программа в первую очередь пишется не для компьютреа,
а для человека, а ваш код совершенно не предназначен для прочтения.
Да вроде нормально, читается не плохо.Вроде все в одном стиле, ткст не разряженный, но дело вкуса.С математикой конечно сложно разобраться, но это в целом не проблема.Коментарии конечно нужны, но только такие что описываю картину в целом, а не то что делает конкретный оператор. Ворде таких:
// Находим корни таким-то методом
// Для опроса каждого устройства создаем отдельный поток
Здравствуйте, Crackjack, Вы писали:
C>Да вроде нормально, читается не плохо.Вроде все в одном стиле, ткст не разряженный, но дело вкуса.С математикой конечно сложно разобраться, но это в целом не проблема.Коментарии конечно нужны, но только такие что описываю картину в целом, а не то что делает конкретный оператор. Ворде таких: C>// Находим корни таким-то методом
C>// Для опроса каждого устройства создаем отдельный поток
C>// устанавливаем параметры COM-порта в соответствие со C>// спецификацией протокола обмена с APC's smart protocol C>// http://eu1.networkupstools.org/protocols/apcsmart.html
C>// просто fuck!
Самые распространенные забыли:
// Durty HACK
// TODO
(забавно, у меня такие комментарии Kate особо подствечивает).
Без таких комментариев можно всё сломать, решив что это (то или иное) ошибка и её срочно надо исправить.
1)
Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2.
Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения.
Превед, Санниасинчег!
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp
гавнакод. нечитабельно, неоптимизировано, неоткомментировано.
есличо, код читается много чаще, чем пишется. подумай над этим.
Все гуд, мне этот код нравится все больше и больше.Вот только документации под рукой нет, а то бы можно было разобраться о чем речь.Коменты походу будут только мешаться.Я так понимаю, что здесь каждое имя переменной несет смысловую нагрузку.
" Аноним " <0@users.rsdn.ru> wrote in message news:2119453@news.rsdn.ru... > Здравствуйте мастера =) > > Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля. > > Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D > > 1stapp.cpp
Я думаю, тебе интересно будет прочесть книжку Саттера и Александреску "Стандарты программирования на C++. 101 правило и рекомендация". Здесь под словом стандарт подразумевается не стандарт языка C++, а стандарты стиля кодирования.
Posted via RSDN NNTP Server 2.0
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Аноним, Вы писали:
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять.
После просмотра кода мне показалось, что Вам еще рано задумываться о вопросах стиля. Вообще же (когда со временем этот вопрос станет актуальным) есть довольно очевидный способ выработки собственного стиля: попробуйте описать Ваш стиль кодирования. В такой форме, чтобы, руководствуясь этим описанием, ему могли следовать другие люди. При этом будьте готовы приводить аргументы в пользу выбранного Вами варианта из нескольких возможных. Короче говоря, попытайтесь объяснить себе, почему Вы делаете именно так, а не иначе. В процессе и сложится стиль.
P.S. В реальной жизни кодера, написавшего такое, я заставил бы переделывать всё, начиная с использования табуляций.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp
не смог пройти равнодушно мимо такого безобразия!
Итак:
1. Чего мы там пишем в секцию кода? Хакер, ты наш, юный.
2. Отступы должны быть аккуратными
3. Не мешало бы разбить главную функцию, на несколько.
В твоём случае могло бы быть так:
7. дальше в коде идут непонятные циферки и буковки.
А вот чтобы они были понятными, надо вместо циферок использовать правильно именнованные константы. И ещё программист должен уметь грамотно подбирать инструмент.
Здесь ты анализируешь PE заголовок, так используй файл winnt.h (уже включён через windows.h)
там определены все структуры и константы для работы с PE
Например твой код:
HANDLE hfile = CreateFile(...);
if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.return 0;
HANDLE hMap = CreateFileMapping(...);
CloseHandle(hfile); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.if (!hMap)
return 0;
PVOID pMap = MapViewOfFile(...);
CloseHandle(hMap); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.if (!pMap)
return 0;
//... наши великие дела ...
//Внутри все работает на счетчиках ссылок. Отпустили mapping и хендлы освободились автоматически Виндой.
UnmapViewOfFile(pMap);
А вот у меня дор сих пор детская проблема — люблю выравнивание в столбик... Например:
//Бесит что держите семеро :)#define WIDTH 800
#define HEIGHT 600
//А вот так нравится...#define DIMX 800
#define DIMY 600
//И к какому врачу идти не знаю....
Не стыдно попасть в дерьмо, стыдно в нём остаться!
D>HANDLE hfile = CreateFile(...);
D>if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
D> return 0;
вот кстати спорная привычка
D>HANDLE hMap = CreateFileMapping(...);
D>CloseHandle(hfile); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.
первый раз такое вижу, думаю возможны какие нибудь подводные камни
D>//Внутри все работает на счетчиках ссылок. Отпустили mapping и хендлы освободились автоматически Виндой.
D>UnmapViewOfFile(pMap);
возможно. я не в курсе
D>
D>А вот у меня дор сих пор детская проблема — люблю выравнивание в столбик... Например:
D>
D>//Бесит что держите семеро :)
D>#define WIDTH 800
D>#define HEIGHT 600
D>//А вот так нравится...
D>#define DIMX 800
D>#define DIMY 600
D>//И к какому врачу идти не знаю....
D>
//Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
Я тоже когда-то так писал, потом перестал. Компилятор всё равно предупредит (3 >= /W? Тогда мы идем к вам!), а читаемость всё же падает. Читаем-то мы слева направо.
if(FAIL == {здесь какое-то длинное выражение}) // если что? исключительная ситуация?if(FAIL == promptUser("Format drive C:?", RETRY | IGNORE | FAIL)) // а-а, это кнопка!if(promptUser({здесь строки всякие, константы}... // ага, задаем какой-то вопрос, и в зависимости от реакции делаем то или иноеif(promptUser("Format drive C:?", RETRY | IGNORE | FAIL) == FAIL) // понятно
Да и в случае сравнений «<»/«>»/... нарушается или концепция, или здравый смысл.
if(SOME_VALUE == f()) // это еще можно понять...if(SOME_THRESHOLD <= readItTenTimesToUnderstand()) // ??!if(thisIsJustABitSimpler() >= SOME_THRESHOLD) // а это расходится со стратегией для ==.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, demi, Вы писали:
RO>
//Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
RO>Я тоже когда-то так писал, потом перестал. Компилятор всё равно предупредит (3 >= /W? Тогда мы идем к вам!), а читаемость всё же падает. Читаем-то мы слева направо.
Согласен. Другое дело, что хотелось бы, что бы многоуважаемый начинающий знал об этом. Я так тож редко делаю и пишу hr == E_FAIL а не наоборот, (а вообще пишу FAILED(hr)). Это просто, к слову.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
D>>HANDLE hMap = CreateFileMapping(...);
D>>CloseHandle(hfile); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.
K>первый раз такое вижу, думаю возможны какие нибудь подводные камни
D>>//Внутри все работает на счетчиках ссылок. Отпустили mapping и хендлы освободились автоматически Виндой.
D>>UnmapViewOfFile(pMap);
K>возможно. я не в курсе
D>>
Этот код я впервые с пояснениями увидел не где-нибудь, а в boost. Так что посмотрите, там сказано с оговоркой 'seems to be'. Но если такая уважаемая либа делает так, думаю, это не так плохо (наверно кто-то из создателей знает что в потрохах Windows).
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp
Лично я бы порекомендовал:
1) использовать константы с осмысленными именами, а не числовые значения,
2) комментировать назначение блоков кода,
3) отделять блоки кода, несущие определённую смысловую нагрузку, пустыми строками,
4) всё же располагать операторные скобки друг под другом (несколько облегчает чтение),
5) (на будущее) не сильно увлекаться шаблонами, да и вообще, поменьше извращаться (иначе коментировать извраты)
6) писать код в расчёте скорее на новичка или программиста средней категории, нежели на гуру.
Эх, люблю выпить и переспать с кем нибудь!
Но чаще выходит перепить с кем — нибудь и выспаться...
D>HANDLE hfile = CreateFile(...);
D>if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
D>
Ну ладно мы мучаеся, читая наизнанку, но молодежи-то зачем это грузить?
Невозможно чтобы у всех было всё, так как всех много, а всего мало...
D>>HANDLE hfile = CreateFile(...);
D>>if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
D>>
A>Ну ладно мы мучаеся, читая наизнанку, но молодежи-то зачем это грузить?
Roman Odaisky заметил неудобочитаемость данной конструкции. Я не отрицаю.
Кстати, а никто не имеет ничего против названия типа _name данных в классе? (в POD и public не практикую). Вроде по стандарту C++ имена с двумя подчеркиваниями подряд в любом месте слова забронированы, _+Заглваная буква, _+любой символ ТОЛЬКО для глобальных имен. Получается _name в классе безвреден. Лично мне m_ не нравится сильно. Как и венгерка!!! Эта вообще ахтунг! Венгерку ф топку!!!
class A
{
int _num;
int _totalSize;
//so on...
};
Не стыдно попасть в дерьмо, стыдно в нём остаться!
demi wrote:
> Кстати, а никто не имеет ничего против названия типа _name данных в > классе? (в POD и public не практикую). Вроде по стандарту C++ имена с > двумя подчеркиваниями подряд в любом месте слова забронированы, > _+Заглваная буква, _+любой символ ТОЛЬКО для глобальных имен. Получается > _name в классе безвреден. Лично мне m_ не нравится сильно. Как и > венгерка!!! Эта вообще ахтунг! Венгерку ф топку!!!
Да можно и "m_", в бусте иногда попадается "fieldName_", а вариант "_fieldName" я видел только в языках не
обеспечивающих security для обозначения приватных данных или для нестандартных расширений.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, demi, Вы писали:
D>Кстати, а никто не имеет ничего против названия типа _name данных в классе? (в POD и public не практикую). Вроде по стандарту C++ имена с двумя подчеркиваниями подряд в любом месте слова забронированы, _+Заглваная буква, _+любой символ ТОЛЬКО для глобальных имен. Получается _name в классе безвреден. Лично мне m_ не нравится сильно. Как и венгерка!!! Эта вообще ахтунг! Венгерку ф топку!!!
D>
D>class A
D>{
D> int _num;
D> int _totalSize;
D> //so on...
D>};
D>
Можно, разумеется. А по поводу HN зря. Читал статью Джоэла?
По поводу именования — я обычно делаю так:
class X
{
. . .
private:
int i_;
std::deque<std::string> strings_;
Y allTheMembersAreCalledThisWay_;
public:
void regularMemberFunction();
void _somethingQuestionable(); // «handle with care!»
};
Т. о., члены именуются с подчеркиванием в конце, методы — без оного, дебажно-грабельные классы начинают свои имена с подчеркивания, что призвано привлекать внимание. Вот например:
Здравствуйте, Roman Odaisky, Вы писали: RO>А по поводу HN зря. Читал статью Джоэла?
Почитаю внимательно, когда освобожусь.
Вот мои мысли против HN.
Мне не нравиться удлинение имен. Во вторых, усложенение рефакторинга. DWORD dwSize; -> WORD wSize; И все вхождения 'dwSize' надо менять. Зачастую этим пренебрегают, и имена не соответствуют типу, что еще хуже. Так можно обозначить ограниченный набор типов (не user-defined). Это было хорошим решением для asm-кода и местах сопряжения asm-C, где никаких проверок типов нет и отсутствуют "разумные" преобразования.
;Давно не практиковался а асме, не пинайте сильно. Но суть ясна.
dw word_size_var; ;2 bytes
dd dword_var; ;4 bytes
;...
;Забыли что переменная 2 байта, но компилятор съест - возьмет лишних 2 байта.
mov eax, DWORD PTR word_size_var;
Факт ведь, что MS отказалась от HN. К тому же, мы живем не в мире Borland Turbo C 3.1 а в мире VisualStudio + VisualAssist, и для того, чтобы узнать тип переменной, достаточно просто навести на имя мышкой. А если стоит ассист, то вообще ничего делать не надо — он когда редактируешь выводит в своей строке определение символа под курсором редактора(для переменной тип). + ворнинги и все такое Венгерка излишня и утомительна.
А вот различить глобальная, стековая или член класса данная перменная, сложнее и код читается лучше, если видно, где функция обращается к членам класса, stack frame и тд. Так что я за _name (beef!), m_name, name_ в классах, g_name, ::name для глобальных переменных. Остальные — как угодно, но БЕЗ венгерки.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
Для начала определись с правилами кодирования, в частоности, выбери, что ты используешь — пробелы или табуляции.
Удвой число ошибок, если не получается добиться цели.
Здравствуйте, Vladimir D Belousov, Вы писали:
VDB>Самые распространенные забыли: VDB>// Durty HACK VDB>// TODO VDB>(забавно, у меня такие комментарии Kate особо подствечивает).
VDB>Без таких комментариев можно всё сломать, решив что это (то или иное) ошибка и её срочно надо исправить.
Да, есть такое дело. А комменты TODO, я думаю следует писать сразу же и писать то, чего собственно туду, а то уже через час забываешь в каком месте ты чего-то не дописал. В итоге очень интересно наблюдать как вызывается метод базового класса, который вроде уже реализован, нет никаких в нем TODO, а он, собака, как-то ведет себя подозрительно. Забыл записать TODO, вот и не было куска логики. Смотрел код. Долго думал.
D>>//Бесит что держите семеро :)
D>>#define WIDTH 800
D>>#define HEIGHT 600
D>>//А вот так нравится...
D>>#define DIMX 800
D>>#define DIMY 600
D>>//И к какому врачу идти не знаю....
D>>
C>1) C>Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2. C>Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения. C>
Нельзя, если не хотите поиметь проблем от выравнивания структур.
Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны),
а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.
Re: Стиль написания
От:
Аноним
Дата:
25.09.06 06:57
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте мастера =)
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
А>1stapp.cpp
* пользуйся втягиванием в теле функции
* аргументы функций и макросов отделяй пробелами. Так больше воздуха и легче читать.
* Никогда не пользуйся табуляциями. Включи в редакторе текста замену табуляций на пробелы. У тех кто будет пользоваться другим редактором весь текст может оказаться нечитаемым.
* Используй выровненный к колонки текст, например по символу =. Ты привел в комменте определение OPENFILENAME выровненное в голонки. Его легко читать, не так ли? При этом выше его стоит несколько строк, их читать сложнее.
* если строка константная то и определяй ее как константную, например
вместо char mbErrTitle[] = "Error"; используй
const char* mbErrTitle = "Error";
* если массив char используешь как сишную строку с терминированием нулем то используй указатель а не декларацию массива.
* магические константы комментируй
* операции которые нельзя понять сразу тоже комментируй, например
d0 = (*(DWORD*)(PEstart+0x54))-(nos*0x28+0xF8+PEstart-(DWORD)vmem);
Принцип очень простой. Берешь текст, любую строку, и считаешь что ты ее видишь первый раз в жизни, и в ней две ошибки. Их нужно найти и исправить.
* пиши код так чтобы можно было 1) его понять и 2) его отладить спустя два года. Например
*(BYTE*)(vmem+d2) = 0xB9;
*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
*(BYTE*)(vmem+d2+5) = 0xB8;
*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
*(DWORD*)(vmem+d2+10) = 0x40113080;
*(WORD*)(vmem+d2+14) = 0xFAE2;
Определи структуру, поставь указатель на эту структуру на vmem+d2 и в дебаггере будешь видеть что там.
* пиши по одному выполняемому выражению на строку, чтобы в дебаггере тебе же жилось лучше, например
if(d1>0) {d1 = (*(DWORD*)(d0-0x20))+0x1000&0xFFFFF000;}
else {d1 = *(DWORD*)(d0-0x20);};
Здесь дебаггер не сможет отличить шаг проверки от шага выполнения выражения.
* пользуйся едиными правилами применения фигурных скобок, например
else{d2 = d2+1;};
очевидно выбивается из общего стиля.
* OutputDebugString(dsNoImport) должно быть только в отладочной версии, изучи макросы условной компиляции и пользуйся ими.
* Не посылай так далеко как на метку lbl, выполни более читабельно.
* файлам давай осмысленные имена, не привязанные к времени, например без new, old, first и прочие. Что сегодня first — завтра совсем не first.
Хотя ты хотел узнать кто что об этом думает. Лично я думаю что шансы у тебя есть.
Здравствуйте, demi, Вы писали:
RO>>А по поводу HN зря. Читал статью Джоэла? D>Почитаю внимательно, когда освобожусь.
Почитай, много интересного узнаешь.
D>Вот мои мысли против HN. D>DWORD dwSize; -> WORD wSize;
Это Systems Hungarian, с современными IDE идея совершенно бесполезная. А Simonyi придумал совсем другое, Apps Hungarian. Только когда он поведал всей Microsoft о своей разработке, те ничего не поняли и стали писать lpsz.
Пример:
string sAddSlashes(string usStr); // «"» -> «\"» и т. п.usUserName = httpGet("name"); // unsafesUserName = sAddSlashes(usUserName); // safe
sqlQuery("INSERT ... " + sUserName + "...");
sqlQuery("INSERT ... " + usUserName + "..."); // Hey! What do you think you're doing?
sWhatever = usWhatever; // Stop! Danger!
И т. п. Если rIndex — это номер строки в листе Excel, а cIndex — столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза.
Здравствуйте, Аноним, Вы писали:
А>* Никогда не пользуйся табуляциями. Включи в редакторе текста замену табуляций на пробелы. У тех кто будет пользоваться другим редактором весь текст может оказаться нечитаемым.
Ну это уж чересчур. Если использовать табуляции только для отступов, всё будет OK.
Roman Odaisky wrote:
> string sAddSlashes(string usStr); // «"» -> «\"» и т. п. > > *us*UserName = httpGet("name"); // unsafe > *s*UserName = sAddSlashes(usUserName); // safe > > sqlQuery("INSERT ... " + *s*UserName + "..."); > > sqlQuery("INSERT ... " + *us*UserName + "..."); // Hey! What do you think you're doing?
А такое сразу в морг. placeholders на это дело есть.
> sWhatever = usWhatever; // Stop! Danger!
Зачем пытаться впихнуть смысл в 2 буквы?
> И т. п. Если rIndex — это номер строки в листе Excel, а cIndex — > столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза.
Уж лучше rowIndex, colIndex. На чём экономим?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Т.е. если отступ идёт просто на следующий уровень, то табуляция, если отступ "внутрь оператора", то пробелы, по
количеству букв в операторе. Тогда смена размера табуляции влияет только на то, на что надо и ничего не разъезжается.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kan, Вы писали:
>> Здесь при другом размере табуляции будет полный бардак.
kan>Я обычно смешиваю пробелы с табуляцией:
kan>Т.е. если отступ идёт просто на следующий уровень, то табуляция, если отступ "внутрь оператора", то пробелы, по kan>количеству букв в операторе. Тогда смена размера табуляции влияет только на то, на что надо и ничего не разъезжается.
Здравствуйте, kan, Вы писали:
>> sqlQuery("INSERT ... " + *us*UserName + "..."); // Hey! What do you think you're doing? kan>А такое сразу в морг. placeholders на это дело есть.
Ну это уже другой вопрос. Сначала придумали проблему (plainтекстовый язык, который приходится генерить на ходу), а потом решают ее.
>> sWhatever = usWhatever; // Stop! Danger! kan>Зачем пытаться впихнуть смысл в 2 буквы?
Ответ на вопрос «зачем» в названии статьи.
>> И т. п. Если rIndex — это номер строки в листе Excel, а cIndex — >> столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза. kan>Уж лучше rowIndex, colIndex. На чём экономим?
Может, и лучше. Но оба варианта явно лучше, чем index1/index2.
До последнего не верил в пирамиду Лебедева.
Re[3]: Стиль написания
От:
Аноним
Дата:
25.09.06 10:13
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Аноним, Вы писали:
А>>* Никогда не пользуйся табуляциями. Включи в редакторе текста замену табуляций на пробелы. У тех кто будет пользоваться другим редактором весь текст может оказаться нечитаемым. RO>Ну это уж чересчур. Если использовать табуляции только для отступов, всё будет OK. RO>Проблемы будут при использовании табуляций для выравнивания всего, что только можно, вроде такого: RO>
RO>for(std::vector<std::string>::const_iterator i = dataStrings.begin(),
RO>\t \t \t \t \t \t \t \t \t \t \t e = dataStrings.end();
RO>\t i != e;
RO>\t ++i)
RO>
RO>Здесь при другом размере табуляции будет полный бардак.
Не буду заниматься предсказаниями когда что произойдет а когда нет, в каком редакторе, в каком вьюере, какой версии и прочее. Я высказал свою точку зрения, выработавшуюся за 10 лет работы. Основано на статистике работы с многими исходниками на самых разных языках и с разными стилями кодирования. Я учитывал распространенные, малораспространенные редакторы, различные вьюеры, и их подсистемы печати. Если придерживаться правила "табуляция — табу" то проблемы не исчезают конечно но по меньшей мере минимизируются. Если человек хотел совет "как лучше", то это правило подходит, на мой взгляд.
Re[3]: Стиль написания
От:
Аноним
Дата:
25.09.06 12:26
Оценка:
Здравствуйте, johny5, Вы писали:
C>>1) C>>Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2. C>>Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения. C>>
J>Нельзя, если не хотите поиметь проблем от выравнивания структур. J>Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны), J>а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.
Нужно преобразовать к структуре. Выравнивание структур — это еще не самая жуткая фигня. Есть платформы, где переменные целых типов должны располагаться в памяти с адресов, кратных 4-м. На таких платформах, код
C>>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
J>>Нельзя, если не хотите поиметь проблем от выравнивания структур. J>>Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны), J>>а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.
А>Нужно преобразовать к структуре. Выравнивание структур — это еще не самая жуткая фигня. Есть платформы, где переменные целых типов должны располагаться в памяти с адресов, кратных 4-м. На таких платформах, код
C>>>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
А>работать будет не всегда.
На таких платформах и ваш и мой вариант приведёт к краху, потому что сгенерённый код будет одинаков. Не думаю что компилятор генерит всегда неэффективный код считывания по байту только из предположения что смещение, переданное вами может быть не кратным 4м.
Всё таки это должно быть на совести программиста.
Re: Стиль написания
От:
Аноним
Дата:
26.09.06 05:38
Оценка:
Здравствуйте, Аноним, Вы писали:
...твой папа тебе благодарен не будет...
Да и коллеги оставят тебя калекой! Ты через год сам побежишь покупать машину времени? когда будешь разбираться в своих сорцах, чтобы сломать самому себе руки и выбить зубы, за такой код!
Roman Odaisky wrote:
>> > sqlQuery("INSERT ... " + *us*UserName + "..."); // Hey! What do you > think you're doing? > kan>А такое сразу в морг. placeholders на это дело есть. > Ну это уже другой вопрос. Сначала придумали проблему (plainтекстовый > язык, который приходится генерить на ходу), а потом решают ее.
Да нет, это от непонимания того, что программа и данные — вещи разделяемые. Если программу можно генерить, это вовсе не
означает, что туда надо пихать все данные.
>> > sWhatever = usWhatever; // Stop! Danger! > kan>Зачем пытаться впихнуть смысл в 2 буквы? > Ответ на вопрос «зачем» в названии статьи.
Я не понял. Автор просто говорит, давайте Unsafe String обозначать как us, а Safe как s. И всё. А без этого соглашения
никто код не поймёт — читабельности это добавляет мало. В общем, ничем не лучше, чем lpsz. Лично я бы писал
userNameUnescaped или даже userNameUnsafeString, unsafeStrUserName, но двухбуквенные аббревиатуры — упаси боже. Пока я
не прочёл в статье что эти буквы значат — я не понял что это значит. Ещё на несколько широко известных и легко
понимаемых сокращений типа col, str, func, ret, bool, pwd, id и т.д. я согласен, но не более.
А вообще говоря, все эти фокусы — от неправильной архитектуры — котлеты и мухи должны быть отдельно. Если у тебя SQL —
есть байндеры, и никогда не надо сувать ничего в текст запроса, если это HTML — есть куча генераторов, скажем XML->XSLT
или куча разных web-движков, которые лучше знают что и где и как кодировать.
>> > И т. п. Если rIndex — это номер строки в листе Excel, а cIndex — >> > столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза. > kan>Уж лучше rowIndex, colIndex. На чём экономим? > Может, и лучше. Но оба варианта явно лучше, чем index1/index2.
Никто не спорит, но всё-таки row лучше чем r, а col лушче чем c
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Стиль написания
От:
Аноним
Дата:
26.09.06 13:29
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
Удача в кодинге — это, сильно !!!
Пожелай мне удачи в кодинге, пожелай