C>1)
C>Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2.
C>Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения.
C>

C>*(BYTE*)(vmem+d2) = 0xB9;
C>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
C>*(BYTE*)(vmem+d2+5) = 0xB8;
C>*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
C>

Нельзя, если не хотите поиметь проблем от выравнивания структур.
Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны),
а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)

А>Я начинающий кодер на 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"); // unsafe
sUserName = 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.

int f()
{
\t  g();
\t  while(h())
\t  {
\t  \t  i();
\t  \t  j();
\t  \t  if(k())
\t  \t  {
\t  \t  \t  break;
\t  \t  }
\t  }
}

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

for(std::vector<std::string>::const_iterator i = dataStrings.begin(),
\t  \t  \t  \t  \t  \t  \t  \t  \t  \t  \t   e = dataStrings.end();
\t  i != e;
\t  ++i)

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

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. На чём экономим?

Roman Odaisky wrote:

> Здесь при другом размере табуляции будет полный бардак.
Я обычно смешиваю пробелы с табуляцией:

if(_____a == "1")
{
\t do(1);
}
else if(a == "2")
{
\t do(2);
\t for(int i=0;
\t ________i<10;
\t ________++i)
\t {
\t \t blah();
\t }
}

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

Здравствуйте, 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.

Здравствуйте, 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 лет работы. Основано на статистике работы с многими исходниками на самых разных языках и с разными стилями кодирования. Я учитывал распространенные, малораспространенные редакторы, различные вьюеры, и их подсистемы печати. Если придерживаться правила "табуляция — табу" то проблемы не исчезают конечно но по меньшей мере минимизируются. Если человек хотел совет "как лучше", то это правило подходит, на мой взгляд.

Здравствуйте, johny5, Вы писали:


C>>1)
C>>Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2.
C>>Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения.
C>>

C>>*(BYTE*)(vmem+d2) = 0xB9;
C>>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
C>>*(BYTE*)(vmem+d2+5) = 0xB8;
C>>*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
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м.
Всё таки это должно быть на совести программиста.

Здравствуйте, Аноним, Вы писали:

...твой папа тебе благодарен не будет...

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

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

Здравствуйте, Аноним, Вы писали:

А>Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.

Удача в кодинге — это, сильно !!!
Пожелай мне удачи в кодинге, пожелай

Здравствуйте, <Аноним>, Вы писали:

А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D

А ты сам через пол-года его открой и услышишь :D

S>Венгерка хде?

Осталась в бейсике.