Naming Conventions & Programming Styles
Dean Wooldridge
Is there an established naming convention for Delphi objects or perhaps a
set of recommendations on naming style? I'm real new to this and still a
bit confused. It seems that naming an object (like a form) "XYZ" and then
trying to save the thing in a file named "XYZ" is a no-no. I guess there
can't be a "unit XYZ" and a form "XYZ"? if that's the case, is it important
to relate the disk file name to the form contained within?
The book I'm reading tends to put lots of objects in a single "unit" - is
that they way it is done in the real world?
What about situations where you are ultimately going to build multiple
applications (read EXE files) but some of your code (procedures/subroutines
and possibly utility forms) will be common - any special handling here?
Appreciate the feedback.
dean wooldridge
G. Bradley MacDonald
there are various naming conventions that are used. One of the more common
ones I have seen metioned is a series of 3 letter abbr. for the component
... so for example a ComboBox that is used to hold a list of ball players
might be cbxBallPlayers.
However, personally I do not like the abbreviations I have seen out there.
You have to learn them and use them so often that you know them cold. Then
what happens when you bring a new person on staff as either a full time or
contractor - they have to learn them. So, personal preference is to do
something along the following...
ListBox - ListBox_BallPlayer
ComboBox - ComboBox_BallPlayer
DBEdit - DBEdit_BallPlayer
etc., etc., etc.
As for form and unit names I prefer the following. If you have a form for
maintaining Ball Players - would probably name the form
'Form_BallPlayerMaint' and the unit 'UnitForm_BallPlayerMaint'. This shows
a direct relationship between the two. It also helps with the maintenance
of the applications. A unit to hold a component would be named
UnitComp_BallPlayer, a unit to hold a datamodule would be UnitDM_BallPlayer,
etc.. While this is a rather simplistic naming convention, I find that it
helps me keep things straight.
--
G. Bradley MacDonald
Delphi & AS/400 Consultant
Dean Wooldridge wrote in message <7o9ms4$p1...@forums.borland.com>...
Michael Beck
http://community.borland.com/article/1,1410,22,00.html
Some of the things described there might be of help.
Michael
Dean Wooldridge wrote:
>
> maybe a technical queestion, maybe not.
>
> Is there an established naming convention for Delphi objects or perhaps a
> set of recommendations on naming style? I'm real new to this and still a
Michael Beck
http://www.borland.com/techvoyage/jediinitiative.html
Michael
Jeff Butterworth wrote:
>
> Except the delphi style guide link is broken
>
> Michael Beck wrote in message <37A86B3C...@NOSPAMdaytonoh.ncr.com>...
Michael Beck
it will be always a personal preference. I've seen top-notch programmers
who prefer one or the other methods. So use whatever suites you better.
Unless your boss tells you differently <g>
I personally prefer the Borland way, because it looks better on nested
begin...end blocks, especially, if you have 3-5 levels. But I also use
20" monitor with 1280x1024, so I can see a lot of lines <g>
Michael
Eric Pascual wrote:
>
> After reading the pointed document, I'd like to know the justifications of
> the rules relative to "begin" indentation.
>
> I confess beeing an adept of the "hanging begin" style, for one reason : it
> avoids wasting a line for the begin world, and thus it gives more chances to
> see the whole source of a given sequence without scrolling.
>
> Of course I do not pretend that this is the right way to indent code (it
> does not follows rules documented on Borland's site). And I do not want to
> start a "begin style" war in this NG :-)
>
> Eric
Jeff Butterworth
Michael Beck wrote in message <37A86B3C...@NOSPAMdaytonoh.ncr.com>...
>Take a look at the "official" Delphi Style Guide, available from:
>
>http://community.borland.com/article/1,1410,22,00.html
>
>Some of the things described there might be of help.
>
Eric Pascual
the rules relative to "begin" indentation.
I confess beeing an adept of the "hanging begin" style, for one reason : it
avoids wasting a line for the begin world, and thus it gives more chances to
see the whole source of a given sequence without scrolling.
Of course I do not pretend that this is the right way to indent code (it
does not follows rules documented on Borland's site). And I do not want to
start a "begin style" war in this NG :-)
Eric
Michael Beck a écrit dans le message
<37A8BCC0...@NOSPAMdaytonoh.ncr.com>...
>OK, try:
>
>http://www.borland.com/techvoyage/jediinitiative.html
>
>Michael
>
>Jeff Butterworth wrote:
>>
DRS
news:7oahia$pp...@forums.borland.com...
: After reading the pointed document, I'd like to know the justifications
of
: the rules relative to "begin" indentation.
:
: I confess beeing an adept of the "hanging begin" style, for one reason :
it
: avoids wasting a line for the begin world, and thus it gives more chances
to
: see the whole source of a given sequence without scrolling.
I prefer the indented begin-end block because I find it easier to identify
nested blocks.
--
"Let the credulous and the vulgar continue to believe that all mental woes
can be cured by a daily application of old Greek myths to their private
parts"
Nabokov on Freud
Robert Claffie
>I confess beeing an adept of the "hanging begin" style,
The "hanging begin" drives me up a wall. Because I'll be following
blocks of code down the left-hand margin, and all of a sudden, I've got
an "end" w/o an obvious "begin." PANIC MODE!
--
Robert Claffie Jr.
Programmer/Analyst
Benefit Concepts, Inc.
10 Risho Ave.
East Providence, RI 02914
(401) 438-7100
Gary Wilmot
<rcla...@benefitconceptsinc.com> wrote:
>From: "Eric Pascual" <eric_p...@compuserve.com>
>
>>I confess beeing an adept of the "hanging begin" style,
>
>The "hanging begin" drives me up a wall. Because I'll be following
>blocks of code down the left-hand margin, and all of a sudden, I've got
>an "end" w/o an obvious "begin." PANIC MODE!
These things are so trivial yet have so much of an effect. I use an
IDE add-in called "DelForEx" which formats the code to _my_ liking and
I don't get hassled by the style (or lack thereof) used by others.
To be honest, I don't know why Delphi doesn't have source code
formatting built in, and profiling, and...... :-)
--
Gary Wilmot
Senior Developer
Vizual Business Tools Ltd
http://www.vizual.co.uk
Rudy Velthuis
>These things are so trivial yet have so much of an effect. I use an
>IDE add-in called "DelForEx" which formats the code to _my_ liking and
>I don't get hassled by the style (or lack thereof) used by others.
I use it too and can recommend it to everyone. It can even use the
current file of files to find the spelling of identifiers as a base for
it's list. so once it finds WM_USER it will include it in the list and
always change wm_User into WM_USER.
The formatting options are quite flexible, also the hanging begin can be
done, if desired.
--
Rudy Velthuis
Steve Griffiths
Thanks... Steve Griffiths
Michael Beck
Mike Carey
"hanging begins", which used to drive me crazy. Now I just look at them
funny, right before I re-format their code! :)
Rudy Velthuis <rvel...@gmx.de> wrote in message
news:MPG.1213e5dfc...@forums.borland.com...
> Gary Wilmot wrote:
>
> >These things are so trivial yet have so much of an effect. I use an
Rudy Velthuis
>Anyone want to offr a URL for DelForEx ??
From the readme:
Q: Where can I find your free formatter?
A: Torry Pages (http://www.torry.ru), the fastest way to find
it there is to go to the authors page and find my name
or The Delphi Super Page (http://sunsite.icm.edu.pl/delphi/)
The author's name is Egbert van Nes (he's Dutch, of course)
--
Rudy Velthuis
Steve Griffiths
Steve Griffiths
Rudy Velthuis wrote in message ...
Fernand Raynaud
miserable Pascal leftover where a single line and a multi-line if .. then ..
else work completely differently. I don't know how many times I've chased
bugs caused by someone adding a line of code within a conditional or an
exception handler, and it compiled fine, only to do something entirely
unexpected. Can someone explain why the "try" block does not use begin...end
while the "catch" does? If only there was something in OP like the C++ curly
brace instead of the archaic begin...end mess. So in the absence of that, is
the only safe way to write code to always use a begin... end? I've tried
that. And then they start bitching about the "wasted" lines, while Borland
recommends "wasting" THREE lines for end begin else begin or do we leave out
a begin? Aaaahrgh!
Then a lot of experienced Win32 developers advocate variable prefixing, with
generous use of whitespace, but all the turbo Pascal veterans prefer
"personally meaningful" variables with no prefixing, and code with no blank
lines, that is indented one or two spaces and looks like the Tokyo subway at
8:00 am. I dunno, these languages are pretty pretty funky. There's a bit of
a problem here. Good luck with "learning" how to do it right.
Fernand
Mike Carey <mca...@mtcarey.com> wrote in message
news:7od8vu$s3...@forums.borland.com...
Fernand Raynaud
This is a contentious issue, but another naming convention that SOME of us
consider important is:
Simple variables to be prefixed with a type indicator, e.g. i for integer, l
for long, r for real, v for variant etc, and a scope marker, g_ for global,
m_ for class member etc. So aside from the standard Hungarian prefixes for
controls and objects like Brad listed, we would use:
m_iUserCount for a class member integer
m_sUserName for a member string
m_szUserName for a member PChar (zero terminated ANSI string)
g_wsUserName for a global Wide String (Unicode)
sUserName for a local string variable
In this scheme variables and controls always start with lower case
prefixing, and procedures/methods always start with upper case. Thus
CalcUserName (or even UserName) would be a precedure, not a variable. This
frees you from the need to keep re-inventing more unique names, since the
same root name can be varied just with prefixes, it helps with sorting and
looking up variables, and provides a lot of information to the reader
without having to keep looking up declarations.
This whole naming convention is pretty widely accepted in the Win32 C++
world. Delphi's Object Pascal is a bit of a mish-mash of Borland Turbo
Pascal and C++, a moving target where e.g. things like overloading are
partly added by Borland as we go, and it has not developed a consistent a
set of guidelines.
There is a Delphi-only convention which is to use "F" to prefix class
members. You see this a lot in the VCL source. I suppose it's viable, but it
does not provide type info, and the upper case "F" visually merges with the
variable name, so I find it inferior. To each his own.
The main argument against the use of prefixing (a.k.a. Hugarian notation) is
that is "reduces legibility". But the lower case prefixes vanish from view
when you read the code after a few days of getting used to it, and if you
ever have to maintain code I think you will thank the gods if this
convention was used.
Fernand
Brad Clarke <bgcl...@iname.com> wrote in message
news:37aeb5f8...@forums.borland.com...
> On Wed, 4 Aug 1999 10:44:48 -0500, "Dean Wooldridge"
> <de...@medsweb.com> wrote:
>
> >>Is there an established naming convention for Delphi objects or perhaps
a
> >>set of recommendations on naming style?
>
> I use Hungarian notation for naming components. Here is a list of
> names that was published in Delphi Informant in 1997.
>
> Brad
>
> *****************************
>
> bar ProgressBar, StatusBar, TrackBar
> bat BatchMove
> btn Button, BitBtn, SpeedButton
> bvl Bevel
> cal Calendar
> cbx ComboBox, DBComboBox
> chk CheckBox, DBCheckBox
> dbs Database
> dec DDEClientConv
> dci DDEClientltem
> dir DirectoryOutline
> dlg Dialogs (Open, Save, Font, Color, Print, PrinterSetup, Find,
> Replace)
> drv DriveComboBox
> dsc DDEServerConv
> dsi DDEServerItem
> dtm DataModule
> dts DataSource
> edt Edit, DBEdit, SpinEdit
> feb FilterComboBox
> frm Form
> ftp FTP (Internet File Transfer Protocol)
> gge Gauge
> grd ColorGrid, DrawGrid, DBGrid, DBControlGrid, StringGrid
> grf ChartFX, VCFirstImpression, GraphicsServer
> grp GroupBox
> hdr HeaderControl, Header
> hot Hotkey
> htm HTML (Internet Web Browser)
> htt HTTP (Send, Receive or Search HTML Documents)
> ibe IBEventAlerter
> img Image, DBlmage
> lbl Label, DBText
> lst ListBox, DBListBox, DirectoryListBax, FileListBox, Imagelist
> luc DBLookupComboBox, DBLookupCombo
> lul DBLookupListBox, DBLookupList
> Ivw ListView
> med MediaPlayer
> mmo Memo, DBMemo, RichEdit
> mni MenuItem
> mnu MainMenu
> msk MaskEdit
> nav DBNavigator
> nbk Notebook, TabbedNotebook
> nnt NNTP (Internet Network Newsgroup Access)
> ole OLEContainer
> out Outline
> pbx PaintBox
> pge PageControl
> pnl Panel
> pop POP (Internet Post Office Protocol to receive E-Mail)
> pum PopUpMenu
> qrb QRBand
> qrc QRCalc
> qrd QRSysData
> qrg QRGroup
> qrl QRDetailLink
> qrm QRMemo
> qrp QuickReport
> qrv QRPreview
> qrs QRShape
> qrt QRLabel, QRDBText
> qry Query
> rad RadioButton
> rgp RadiaGroup, DBRadioGroup
> rpt Report
> sbr Scrollbar
> sbx Scrollbox
> shp Shape
> sht VCFormulaOne
> smt SMTP (Internet Simple Mail Transpart)
> spl VCSpeller
> spn SpinButton, UpDown
> ssn Session
> stp StoredProc
> tab TabControl, Tabset
> tbl Table
> tcp TCP (Internet Data Exchange ... like a telephone)
> tmr Timer
> tre TreeView
> udp UDP (Internet Data Br~odcost ... like a radio)
> ups UpdateSQL
Fernand Raynaud
Fernand
Steve Griffiths <sg...@teleport.com> wrote in message
news:7oetud$dt...@forums.borland.com...
Stefan Hoffmeister (TeamB)
>Does anyone know of such a fomatter for BCB?
There is a GNU tool for that out there.
Please check http://www.deja.com/ for a posting of mine in
cppbuilder.thirdpartytools
--
Stefan Hoffmeister (TeamB) http://www.econos.de/
Please do apply judgement when sending email.
Rudy Velthuis
>Does anyone know of such a fomatter for BCB?
BuilForEx?
Sorry, just kidding. No I don't.
--
Rudy Velthuis
Gary Wilmot
wrote:
>Fernand Raynaud wrote:
>
>>Does anyone know of such a fomatter for BCB?
>
>BuilForEx?
>
>Sorry, just kidding. No I don't.
Wouldn't that be CBuForEx? :-)
Gary Wilmot
<fer...@elysee.fr> wrote:
>brace instead of the archaic begin...end mess. So in the absence of that, is
>the only safe way to write code to always use a begin... end? I've tried
>that. And then they start bitching about the "wasted" lines, while Borland
>recommends "wasting" THREE lines for end begin else begin or do we leave out
>a begin? Aaaahrgh!
Oooh another religious war about to start <G>
I make a point of using begin...end "just in case" - for _me_ it makes
things clear and the structure is in place already if more conditional
code needs adding.
Just my tuppence worth really..
Frederick C. Wilt
news:7ol7iv$5q...@forums.borland.com...
> brace instead of the archaic begin...end mess. So in the absence of that,
is
> the only safe way to write code to always use a begin... end? I've tried
> that. And then they start bitching about the "wasted" lines, while Borland
> recommends "wasting" THREE lines for end begin else begin or do we leave
out
The following is a acceptable form (see Code Complete):
if () then begin
end else begin
end;
Regards, Frederick C. Wilt
Mike Carey
is relatively uncommon in Pascal, it's extremely common in C.'
Frederick C. Wilt <fcw...@mindspring.com> wrote in message
news:7omqr9$7i...@forums.borland.com...
Rudy Velthuis
BuilForEx?
>>
<<Gary:
Wouldn't that be CBuForEx? :-)
>>
Well, BuilForEx sounds better than CBuForEx (although some Filipinos
might not agree - Cebu is a large town in the Philippines). Any way,
DelForEx was quite appropriate. Since the demission, they should give it
a new name (DaleForNow?)
--
Rudy Velthuis
Frederick C. Wilt
> See page 415: 'An interesting sidenote on this style is that even though
it
> is relatively uncommon in Pascal, it's extremely common in C.'
>
Hmm... Are you saying that because it is uncommon it is not to be used? I
came from a C background and used this form from the beginning since:
1: It just made sense to me.
2: I prefer to see as much of my code on the screen at one time as I can.
Now if uncommon = not good then we might argue that common = good. Therefore
we can conclude that MS writes good code because it is commonly full of
bugs. <g>
Regards, Frederick C. Wilt
Fernand Raynaud
the situation. For some reason Borland doesn't like it. I would prefer to
have the else up front in the second line where I could see it better, but
that's how it goes. No way I'm leaving out the begin...end bracketing any
more after all those subtle jumps into inner space upon adding a line of
code.
So now, Federick, how do you deal with the try .. except ... end confusion?
Fernand
Frederick C. Wilt <fcw...@mindspring.com> wrote in message
news:7omqr9$7i...@forums.borland.com...
> Fernand Raynaud <fer...@elysee.fr> wrote in message
> news:7ol7iv$5q...@forums.borland.com...
> > brace instead of the archaic begin...end mess. So in the absence of
that,
> is
> > the only safe way to write code to always use a begin... end? I've tried
> > that. And then they start bitching about the "wasted" lines, while
Borland
> > recommends "wasting" THREE lines for end begin else begin or do we leave
> out
>
Fernand Raynaud
Indent, which is what you were ***referring to, unfortunately only works for
C, not C++.
Fernand
Stefan Hoffmeister (TeamB) <Stefan.Ho...@Econos.de> wrote in message
news:37b09ee9...@forums.inprise.com...
> : "Fernand Raynaud" <fer...@elysee.fr> wrote:
>
> >Does anyone know of such a fomatter for BCB?
>
Eric Pascual
Michael Beck a écrit dans le message
>Eric,
>
>it will be always a personal preference. I've seen top-notch programmers
>who prefer one or the other methods. So use whatever suites you better.
>Unless your boss tells you differently <g>
>
Eric
Liz Kimber
<type><sensible name>
aka
btnOK Button labelled OK
btnCancel Button labelled Cancel
lblName Label labelled Name
txtName Editbox/Textbox depending on language labeled Name
iLoop Integer called loop
sName String called Name
etc
Philippe Ranger
I confess beeing an adept of the "hanging begin" style, for one reason : it
avoids wasting a line for the begin world, and thus it gives more chances to
see the whole source of a given sequence without scrolling.
>>
I'm an adept too, and also of "horizontal coding" generally. I don't like to
break stuff that goes together with newline. But the argument for Borland's
standard is that it's easier to see the begin-end brackets match on their
own column. (Which means that the hand-formatting is supposed to keep in
step with the way the compiler will see it -- no rule will ensure that the
End matching some Begin on its column is actually the correct End.)
PhR
Philippe Ranger
Oh, this DelForEx sounds great! Ah, but while you format, don't forget the
miserable Pascal leftover where a single line and a multi-line if .. then ..
>>
You don't mean multi-line, you mean multi-statement. Not a formatting issue.
<<
So in the absence of that, is
the only safe way to write code to always use a begin... end? I've tried
that. And then they start bitching about the "wasted" lines, while Borland
recommends "wasting" THREE lines for end begin else begin or do we leave out
a begin? Aaaahrgh!
>>
Yep, if you don't want to add the bracketting when you add a statement, the
only way is to have begin-ends everywhere where a block might later grow. I
think it makes stuff less readable, no matter the formatting.
<<
but all the turbo Pascal veterans prefer
"personally meaningful" variables with no prefixing
>>
I'm a TP vet and a Hungarian addict.
<<
and code with no blank
lines, that is indented one or two spaces and looks like the Tokyo subway at
8:00 am.
>>
If you go by the Borland standard and have separate lines for begin and end,
your actual blocks will be double-indented, so using more than a 2-space
indent will be a hindrance. I don't know why people who love putting a
single word on one line hate leaving any line blank, but that's the way it
goes. Seems only we "horizontal" coders realize blanks are useful.
PhR
Philippe Ranger
Hmm... Are you saying that because it is uncommon it is not to be used?
>>
I'd say that advice from Code Complete is always a reason to reach for the
salt shaker. In this case, C has a problem with it's low-visibility brackets
(the braces). Some C coders isolate them, as per the Borland style guide for
Delphi, and imho that really does not help readability -- you have an
essentially blank line precisely where you don't mean to separate anything.
Conversely, a closing brace at the start of a line certainly does not stop
the eye. However, a line that begins with "end;" and goes on to something
else is a bit misleading. I suppose one can get used to it.
Me, I waste a line for the end, in line with the block it ends, just to make
super-clear the block ends where it looks like it's ending.
PhR
Philippe Ranger
But the lower case prefixes vanish from view
when you read the code after a few days of getting used to it, and if you
ever have to maintain code
>>
Ok for lowercase. But those underlines! Trick spaces for the eye.
PhR
Frederick C. Wilt
> So now, Federick, how do you deal with the try .. except ... end
confusion?
For whatever reason I have not found try .. except ... end to be confusing.
Could you elaborate?
Regards, Frederick C. Wilt
Frederick C. Wilt
Philippe Ranger <.> wrote in message news:7opdr1$9u...@forums.borland.com...
> Me, I waste a line for the end, in line with the block it ends, just to
make
> super-clear the block ends where it looks like it's ending.
Well difference just makes the world a more intersesting place.
Howerver to me
if () then begin
end;
is just as clear as and less cluttered than
if () then
begin
end;
I find matching the 'end' to the 'if' more natural (i.e. what type of block
I am at the end of). Heck if OP required the 'end' as do some langs we would
have the 'begin' at all. Go figure.
I only use two styles for ifs. Sometimes 'if () then do-something' if it is
simple and clear and fits on one line, otherwise its 'if () then begin
end;'. I can't tell you how many times I have seen folks add a statement (or
three) to an existing 'if' and forget to add the 'begin/end';
Just me.
Regards, Frederick C. Wilt
Philippe Ranger
Howerver to me
if () then begin
end;
>>
You misread me. This is what I do. My message was regarding the end, not the
begin.
PhR
Karl Waclawek
"Frederick C. Wilt" wrote:
>
> Fernand Raynaud <fer...@elysee.fr> wrote in message
> news:7ol7iv$5q...@forums.borland.com...
> > brace instead of the archaic begin...end mess. So in the absence of that,
> is
> > the only safe way to write code to always use a begin... end? I've tried
> > that. And then they start bitching about the "wasted" lines, while Borland
> > recommends "wasting" THREE lines for end begin else begin or do we leave
> out
>
> The following is a acceptable form (see Code Complete):
>
> if () then begin
> end else begin
> end;
>
Just to throw another indentation style into the discussion:
I usually follow the idea that if a line symbolizes a block,
everything following this line (and belonging to this block)
is indented. Exceptions: Alternate blocks, like with an
if then ... else ... or case ... of statement are at the same
level of indentation:
Example:
function MyObject.MyExampleFunc(Arg1: string; Arg2: Integer): string;
var
LocalVar1: TDateTime;
LocalVar2: string;
Indx: Integer;
LocalProc DoSomeLocalStuff(Arg: string);
var
LocalLocalVar: Integer;
begin
<statements>
end;
begin
<statements>
for Indx := 0 to SomeList.Count - 1 do
begin
<statements>
end;
if Condition then
begin
<statements>
end
else
begin
<statements>
end;
case <ordinal> of
2: <statement>;
234:
begin
<statements>
end;
else
<statements>;
end;
repeat
<statements>
until <condition>;
end;
Karl
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Waclawek
KD Soft Inc.
* Phone: (905) 579-3443
* E-Mail: wacl...@idirect.com
Mike Carey
inherent superiority in what is "common" beyond its "commonness". I once
saw code like this from a state-employed programmer:
begin
if x = y then begin
....
end;
DoSomething;
DoSomethingElse;
for i := 0 to 9 do begin
....
end;
DoSomethingAgain;
x := y;
GiveMeLandLotsOfLand(DontFenceMeIn);
FinishUpThisAbomination;
end;
Now, this "Lone Ranger" had written tens of thousands of lines in this style
(which I referred to as the "Leaning Tower"), and the resulting application
was fine, so who was I to question his "aesthetics" (he said he liked the
way it looks). I just thanked Athena that I would not have to maintain this
mess! My point is that "uncommon" may satisfy the "rebel" in all of us, but
where does it stop? What is acceptable "uncommonness", and what is not?
Frederick C. Wilt <fcw...@mindspring.com> wrote in message
news:7onmam$8c...@forums.borland.com...
Frederick C. Wilt
Philippe Ranger <.> wrote in message news:7opqrs$aa...@forums.borland.com...
> You misread me. This is what I do. My message was regarding the end, not
the
> begin.
Well... uh... er.... good!
Regards, Frederick C. Wilt
Frederick C. Wilt
Karl Waclawek <wacl...@idirect.com> wrote in message
news:37B07440...@idirect.com...
>
Any style that works for you is the correct one. My objection to this
classic style is that each begin and else take up an entire line by
themselves reducing the amount of code visible on the screen.
Regards, Frederick C. Wilt
Karl Waclawek
That is a valid objection.
I have played with the idea of having the "begin" at the
end of the line that starts the block, but haven't
really tested it out in practical life yet.
Ceci Gross
I usually follow the idea that if a line symbolizes a block,
everything following this line (and belonging to this block)
is indented.
<<
YES!!
I've never seen anyone that does it "my" way, including indenting
everything under the function or procedure. This is the most consistent and
readable for me. I deal with try..finally stuff by capitalizing the
keywords, including the closing END. I also don't indent things under TRY,
but I do indent under FINALLY and EXCEPT. So:
function Somefunc;
begin
myobj := TMyObject.Create;
TRY
myobj.DoStuff;
myobj.DoOtherStuff;
FINALLY
myobj.free;
END;
end;
--Ceci.
oz
I have...placing the 'BEGIN" at the end of the line that starts,
say, and If(condition) Then is the only way to code.
I make no apologies for the firmness of my statement. I have
tried all other combinations and this is the only one that works in
terms of legibility.
Oz
Mike Mormando
Style and Convention, not a rule. My reason?
if (MyNicelyNamedRecognizeableVariable =
0)and(MyNicelyNamedRecognizeableVariable2>SOMECONSTANTNAMEDSOMEWHERE)and(ITh
inkYouGetWhereImGoingWithThis) then
begin
end;
I personally can see where the conditions end, and the code starts faster
this way than having the begin right after the then.
Mike
oz wrote in message <7or8pt$be...@forums.borland.com>...
Mark Reichert
news:7orua1$cf...@forums.borland.com...
> In your opinion. I have the opposite opinion. That's why it's called a
> Style and Convention, not a rule. My reason?
>
> if (MyNicelyNamedRecognizeableVariable =
>
0)and(MyNicelyNamedRecognizeableVariable2>SOMECONSTANTNAMEDSOMEWHERE)and(ITh
> inkYouGetWhereImGoingWithThis) then
> begin
>
> end;
Well, if you're going to use run-on names for variables and constants, then
of course the begin needs to go on its own line.
--
Please respond only in the newsgroup. I will not respond
to newsgroup messages by e-mail.
Mike Mormando
Mike
Mark Reichert wrote in message <7orvi2$cf...@forums.borland.com>...
>> if (MyNicelyNamedRecognizeableVariable =
>>
>0)and(MyNicelyNamedRecognizeableVariable2>SOMECONSTANTNAMEDSOMEWHERE)and(IT
Ray Wright
person stated. Use what works for you.
oz <ozb...@bigpond.com> wrote in message
news:7or8pt$be...@forums.borland.com...
> Karl...
>
> I have...placing the 'BEGIN" at the end of the line that starts,
> say, and If(condition) Then is the only way to code.
>
> I make no apologies for the firmness of my statement. I have
> tried all other combinations and this is the only one that works in
> terms of legibility.
>
> Oz
>
oz
Your example is specious and its illegibility has far, far more to
to with lack of spacing than anything else.
Oz
"Mike Mormando" <mi...@mormando.com> wrote:
>In your opinion. I have the opposite opinion. That's why it's called a
>Style and Convention, not a rule. My reason?
>if (MyNicelyNamedRecognizeableVariable =
>0)and(MyNicelyNamedRecognizeableVariable2>SOMECONSTANTNAMEDSOMEWHERE)and(ITh
>inkYouGetWhereImGoingWithThis) then
>begin
>end;
>I personally can see where the conditions end, and the code starts faster
>this way than having the begin right after the then.
>Mike
>oz wrote in message <7or8pt$be...@forums.borland.com>...
Mike Mormando
express it.
Even if it is one of the less intelligent things I've become aware of
lately.
Mike
oz wrote in message <7p0msh$h8...@forums.borland.com>...