2006/6/3, Vincent Snijders <[EMAIL PROTECTED]>:
Burkhard Carstens wrote:
> Am Samstag, 3. Juni 2006 02:29 schrieb Mattias Gaertner:
>
>>On Fri, 2 Jun 2006 20:21:01 -0400
>>
>>"Alexandre Leclerc" <[EMAIL PROTECTED]> wrote:
>>
>>>2006/6/2, Burkhard Carstens <[EMAIL PROTECTED]>:
>>>
>>>>[..]
>>>>
>>>>
>>>>>>CORRECT
>>>>>>  FMyString: string;
>>>>>>
>>>>>>INCORRECT
>>>>>>  lpstrMyString: string;
>>>>>>
>>>>>>The exception to the Hungarian notation rule is in enumerated
>>>>>>types.
>>>>>
>>>>>If other developers agree, we should add this to the wiki page.
>>>>>If not, then deviation from this standard should be mentioned.
>>>>
>>>>For variables this is ok, but for components, I also use the
>>>>"btnWhatever" notation. Especially on bigger projects, this helps
>>>>a lot.
>>>>
>>>>Just my 2 cent ..
>>>
>>>Well, I've the same opinion on this. I agree with the documents and
>>>naming convention presented in these documents (especially the
>>>Borland one, which I do follow since many years as best as I can).
>>>But the addition which is in the old document I posted ([2..4]
>>>letters prefix for components) is very usefull for code clearness -
>>>it's all about code readability and clarity. When you can actually
>>>'read' the code and need no comments and searching here and there
>>>about the nature of the control, this is a good thing.
>>
>>Why is btnOk more clear/readable than OkButton?
>
>
> sure,it doesn't matter on a form with two buttons and one label, but I
> have some forms containg some dozend control. Now if I want to change a
> property of that one button, who's name i cant remenber exactly, but I
> now it is a button and it is related to settingn a minimum range for
> something, I just enter "btnMin" Ctrl-Space and code-tools let me
> choose ..

This doesn't completely convince me. If you named your button
MinXXXButton, you could have entered "Min" Ctrl-Space and you could just
pick the button from that list. I am not sure what is easier, typing the
btn prefix or choosing the button from the edits, combobox, labels,
whatever.

Well, in the case you present, there is no issues with code clarity.
But it's more or a cartesian classification; probably derivate of my
background. If all buttons begin the same, it's easier to see them all
together (alphabetically). I can't convince you. It is more elegant
and usefull for me. Might be otherwise for you. But I certenly find
the first more key saving, easier of access, clearer, and elegant.
Examples:
OkButton
btnOk
CancelButton
btnCancel
ProcessInvoiceButton
btnProcessInvoice

It is [control-type/category][control-name] based. I also found that
making automatic stuff is also clean... simple example I did once for
other reasons (I write the code from memory, might not compile):
for i := 0 to ControlCount-1 do
 if Copy(Controls[i].Name, 1, 3) = 'lbl' then
   (Controls[i] as TLabel).Caption := 'Label control' + IntToStr(i);

Yes this code can be done with the 'HereIsALabelLabel' approach. But
looks clean that way for me (again, we talk about personal tastes
here).

Personal tastes can be discussed, not forced :) -- Let's say it: if
every one was coding like me... :) LOL.

I made an error about frmMain. This is another gramatical exception.
Same for QuickReport and DataModules. Because the sourcefile tends to
have the control name, and because my sources follow these rules:
- uUnit
- frmForm
- qrQuickReport
- dmDataModule
then the component name can't follow the rule. This is the only case
the name will have a [name][component] notation. So the actual name
would be: MainForm (frmMain.pas), MainDataModule (dmMain.pas),
MainQuickReport (qrMain.pas) and uMyIndependentUnit. The reason for
uUnit is because I can make quickly the difference between unit that
are external unit of the project or units made for the project. So a
uses clause talks by itself:
uses
 Classes, Forms, uAdvancedFunctions, uAnotherUnit;

The sources files are quickly identifiable (units all together).

Best regards.

--
Alexandre Leclerc

_________________________________________________________________
    To unsubscribe: mail [EMAIL PROTECTED] with
               "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to