Poll: Concise or Simple code? 1

[Griffyn]

Hi all,

There's a certain amount of pride one gets from writing some concise code: that is, the least amount of repetitious and superfluous code that achieves the same thing.

I wrote this simple event block attached to a Button

[navy][i]// for automatic syntax highlighting see faq102-6487 
[/i][/navy][b]procedure[/b] TMainForm.OptionsButtonClick(Sender: TObject);
[b]const[/b]
  arg : [b]array[/b][Boolean] [b]of[/b] String = ([teal]'Hide'[/teal], [teal]'Show'[/teal]);
[b]begin[/b]
  TButton(Sender).Caption := arg[TopPanel.Visible] + [teal]' &Options'[/teal];
  TopPanel.Visible := [b]not[/b] TopPanel.Visible;
[b]end[/b];

and then realised that if written like this:

[b]procedure[/b] TMainForm.OptionsButtonClick(Sender: TObject);
[b]begin[/b]
  [b]if[/b] TopPanel.Visible [b]then[/b]
    OptionsButton.Caption := [teal]'Show &Options'[/teal]
  [b]else[/b]
    OptionsButton.Caption := [teal]'Hide &Options'[/teal];
  TopPanel.Visible := [b]not[/b] TopPanel.Visible;
[b]end[/b];

It's vastly more simple, and yet I prefer the first example because, well, I don't know why exactly. Perhaps because the coding will scale better, even though it will never need to. Perhaps because it has a few less characters or 'code' lines.

My question is: Given the choice, which example would you tend to in your projects?

 

[DelphiAaron]

to me the second looks very clear and to the point.

if someone else had to take over then they should have no problem understanding it with at least basic delphi knowledge. (like myself)

the top code is checking for sender so makes me think that there are other buttons using this block, plus the const declaration using memory.

K.I.S.S. (keep it simple stupid).

Aaron

 

[whosrdaddy]

I like the first example, but I would ditch the TButton(Sender).Caption thing and use the OptionsButton.Caption here, it make the code more readable, which can be very important. Aarom, the first example uses less memory in fact. why? because your code footprint is smaller (only one '&Options' string)

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[sggaunt]

I would say that there are any number of ways to write this that are a combination of the the two examples.

For a single option button click like this I would go for option 2, I tend to use the sender parameter where its differentiating between senders.
Its surplus to requirements here.

If the same text strings are used elsewhere I would probably declare them globally. I might do this anyway, just to keep all the constant definitions together.

(I also write embedded 'C' that probably has something to do with it, In an MCPU Constants declared as above will be stored in RAM, that's something to avoid if at all possible, declaring globally sticks them in the ROM space)


Steve [The sane]: Delphi a feersum engin indeed.

 

[Glenn9999]

Perhaps the wisest course is to write the code that costs the least to maintain. It used to be code like the first example, since memory and drive space was at a premium (i.e. cost much money).

These days, the premium is coder time. Therefore the second wins out. It's the most understandable and least apt to have bugs in it for some reason or another. The goal in this respect is the most readable, most easily understood code which does the job.

You never go wrong in most managerial issues with coding by writing programs for the stranger that comes after you to consume.

 

[trollacious]

I vote for the second example, though I add begin and end to all blocks (and do the same kind of thing in other languages I use, too).

Lee

 

[Stretchwickster]

Griffyn, I understand exactly what you mean when you say you prefer the first example. There is something satisfying about coding a neat, scalable solution.

However, having had to pick up a few projects written by other programmers, I am now much more inclined to agree with Glenn9999. Storage is not at a premium any longer (in most scenarios), so I would also vote for the code which is least likely to be misunderstood i.e. the most readable. Anything that is more immediately clear at first glance should be the goal as it will be much easier for another programmer (or even yourself in a few years time!) to debug/maintain/test/etc.

Clive

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[harebrain]

Think outside the box: it's not an either/or question.

procedure TMainForm.OptionsButtonClick(Sender: TObject);
[b]const[/b]
  arg : [b]array[/b][Boolean] of [b]String[/b] = ([teal]'Hide'[/teal], [teal]'Show'[/teal]);
begin
[navy]  {------------------ PSEUDOCODE -------------------
    if TopPanel.Visible then
      OptionsButton.Caption := 'Show &Options'
    else
      OptionsButton.Caption := 'Hide &Options';
  -------------------------------------------------}[/navy]
  TButton(Sender).Caption := arg[TopPanel.Visible] + [teal]' &Options'[/teal];
  TopPanel.Visible := [b]not[/b] TopPanel.Visible;
[b]end[/b];

You, too, can have the best of both worlds!

 

[Griffyn]

I like the approach harebrain, but I don't want to think about maintaining two copies of the same code .

Thanks for your thoughts everyone. Everyone's provided some valuable insight that I hope we can all draw upon. It's good to get a reading from the community on your own standards every now and again.

 

[BobbaFet]

I like the 2nd one better, my first rule for just about everything:

If it isn't simple, it isn't beautiful and if it isn't beautiful it's wrong.

BobbaFet

if not Programming = 'Severe Migraine' then
                       ShowMessage('Eureka!');

 

[harebrain]

I don't think you'd have to maintain the pseudocode. If it ever comes to expanding the live code, a simple addition to the comment could be made: "This was the original intent of the code, which has since expanded and isn't completely explained here now. But you get the idea."

 

[Stretchwickster]

By writing code in the clearest way possible, a lot more of it would be self-documenting. Comments could then be reserved for larger chunks of code which truly require explanation. Please don't misunderstand me - I'm not discouraging the practice of commenting/documenting code and one rule is not always applicable to all scenarios.

Clive

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[TonHu]

@harebrain: "The worst documentation is not the lack of documentation, but simply wrong documentation."

HTH
TonHu

 

[harebrain]

@TonHu: I don't disagree with your statement, but I don't think I advocated the opposite. There's nothing wrong with acknowledging that a comment is outdated; in fact, it is a "good thing." And knowing the history of a code segment's evolution is often very illuminating.

Question: Do you avoid documentation because you fear getting it wrong, or are you just lazy?

 

[HelpMEDude]

The second, since I wouldn't understand the first one

harebrian - Instead of the code in the {}-tags, can't you just describe with real words what the code does, or even better. Both ?


To be honest, the argument that the first one makes the source take 10B less disk memory is just stupid -.- .

I'm probably wrong, but is it possible to replace "TButton(Sender).Caption" and "OptionsButton.Caption" with "self.caption"?

Remember I'm a noob ^^

 

[Griffyn]

the Self variable in that context would refer to the instance of TMainForm, and not the TButton.

 

[harebrain]

Of course, Dude. Comments are there to make of them what you will. And he who doesn't comment his code won't understand it himself later.

 

[Glenn9999]

Comments can be abused as well. You can comment to the point that you'll never see the code that's there. And for my experience I was in a shop that had a "don't delete anything always comment rule" too. It was so difficult to see what was active code and what was comments.

My rule is if 25% or more of a source file is comments, then there's problems of some nature.

 

[Stretchwickster]

My rule is if 25% or more of a source file is comments, then there's problems of some nature.

Yes, your code is either over-complicated or you have over-commented!

Clive

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[roo0047]

1: Great thread!
2: IMO, the 80/20 Rule applies here:

http://management.about.com/cs/generalmanagement/a/Pareto081202.htm

3: I have a drive with all the code I've ever written, dating back to Borland Turbo Pascal 2.0, plus everything I've collected from other sources. It is my #1 search path when I want to find something. It's most anoying to get more hits in comments than code. Well written code needs no comment. IMO, comments have one purpose: To block out the previous method {OLD... while testing the ...NEW:} Once the NEW is released, the comment gets deleted. (After noting the change in the revision block, of course.)

Roo
Delphi Rules!