|
Looks like the kind of code my last boss would write.... bizzarely enough he seemed to recite "Keep it Simple Stupid" and "Structured Coding Practices" and swore by Code Complete.... like using them as some kind of protective mantra would do any good for the abomination created.
After opening his core business app to find most web pages with 750 line page load functions, dozens of nested conditions (Loop / If / Case anyone?) and all the variables declared at the page leve, which served up a range of pages based on seemingly arbitrary values... i asked for help. "It's in the code, read it."
I did take away some fantastic coding advice:
* Only one return per function (no short circuit conditions), leading to horrendous nesting.
* Don't use Data Access layers, they're a waste of time, just use inline SQL and bind to a DataReader.
* Don't create lots of objects, it's slow.
* Don't break things into sub functions, it's harder to read and slower.
* Don't use constants, it's hard to read the literal representation.
* Don't use Serialization (Xml or otherwise - My understanding of serialization is object state persistence so I'm not sure how to persist without it).
* Don't use wrappers, ever, as you will just end up with wrappers in wrappers.
* Don't use Inheritance, it's complicated.
* Don't use Interfaces, they're unescessary.
* Don't make custom controls
* Don't use design patterns, they just complicate things.
* Don't use code generators, they generate slow / too much code.
* Don't bother with resources until we need to globalize the app.
* Don't make unit tests, waste of time, we can just user test it.
Now, without any of the above application structures, and the functional requirement to add Multi Language support, change the database schema (slighltly), and add cross site functionality to each page....
Needless to say, the code debt was massive, and maintenance was a time sync of code + fix with no coherent strategy.
Did i mention he was the CTO?
Regards
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
modified on Friday, April 3, 2009 6:58 AM
|
|
|
|
|
Tristan Rhodes wrote: * Only one return per function (no short circuit conditions), leading to horrendous nesting.
Not bad advice - just keep your functions short or you're in trouble.
Tristan Rhodes wrote: * Don't use Data Access layers, they're a waste of time, just use inline SQL and bind to a DataReader.
COBOL
Tristan Rhodes wrote: * Don't create lots of objects, it's slow.
COBOL
Tristan Rhodes wrote: * Don't break things into sub functions, it's harder to read and slower.
COBOL
Tristan Rhodes wrote: * Don't use constants, it's hard to read the literal representation.
COBOL
Tristan Rhodes wrote: * Don't use wrappers, ever, as you will just end up with wrappers in wrappers.
COBOL
Tristan Rhodes wrote: * Don't use Inheritance, it's complicated.
COBOL
Tristan Rhodes wrote: * Don't use Interfaces, they're unescessary.
COBOL
Tristan Rhodes wrote: * Don't use Serialization (Xml or otherwise - My understanding of serialization is object state persistence so I'm not sure how to persist without it).
COBOL
Tristan Rhodes wrote: * Don't make custom controls
COBOL
Tristan Rhodes wrote: * Don't use design patterns, they just complicate things.
COBOL
Tristan Rhodes wrote: * Don't use code generators, they generate slow / too much code.
COBOL
Tristan Rhodes wrote: * Don't bother with resources until we need to globalize the app.
COBOL
Tristan Rhodes wrote: * Don't make unit tests, waste of time, we can just user test it.
COBOL
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: BOLOC
Fixed it!
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
Actually, I wrote COBOL so many times so somebody would pluralise the anagram.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: Tristan Rhodes wrote:
* Only one return per function (no short circuit conditions), leading to horrendous nesting.
Not bad advice - just keep your functions short or you're in trouble.
I'd rather see this
MenuItemNode child = tvMenu.SelectedNode as MenuItemNode;
if (child == null)
return;
MenuItemNode parent = child.Parent as MenuItemNode;
if (parent == null)
return;
MenuItemNode swap = child.PrevNode as MenuItemNode;
if (swap == null)
return;
Than This
MenuItemNode child = tvMenu.SelectedNode as MenuItemNode;
if (child != null)
{
MenuItemNode parent = child.Parent as MenuItemNode;
if (parent != null)
{
MenuItemNode swap = child.PrevNode as MenuItemNode;
if (swap != null)
{
}
}
}
I just find the second option ugly, and it really isn't any easier to read.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
modified on Sunday, April 5, 2009 7:33 AM
|
|
|
|
|
I think the same. But no one in my team thinks this way and they have managed to make this as a coding rule.
|
|
|
|
|
Will they let you get away with stuffing all the nested initialization/validation crap into a separate method?
eg something like this (I know it needs a bit more fiddling to compile):
bool IntializeAndvalidate (out MenuItemNode child, out MenuItemNode parent, MenuItemNode swap)
{
MenuItemNode child = tvMenu.SelectedNode as MenuItemNode;
if (child != null)
{
MenuItemNode parent = child.Parent as MenuItemNode;
if (parent != null)
{
MenuItemNode swap = child.PrevNode as MenuItemNode;
return (swap != null);
}
}
}
if (IntializeAndvalidate (child, parent, swap)
{
}
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
The official solution to avoid multiple returns is throwing exceptions all over the place, especially on input validation.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
I've used that method before, but i was always told by my teacher to not use exceptions to control application flow, so it's something I'm reluctant to do unless I'm out of options.
Still, if you want a short circuit validation routine with no input or output, guess that's the only way.
What's the performance hit like for exceptions in ASP.Net? I thought exceptions were super bad at crippling servers?
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Hi,
there is no performance hit for testing and throwing exceptions; what is slow is catching exceptions, especially so for the first one caught inside Visual Studio. But then exceptions should be used to deal with exceptional circumstances only, which does *not* mean they should be used rarely.
It would be a bad idea to use them like so:
int[] numbers=new int[100];
for (int i=0; ; i++) numbers[i]=i;
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
The 'one return per function' rule is a bit old school (early 90's ). IBM had it as a requirement when I was contracting there. It's not so much about style and readability as it is about introducing subtle bugs. If a maintenance programmer has to put some code in the function that has to take place before the function ends, he may place it right before the final 'return' near the end of the code block. And if he was working fast, or just working stupid he may not know of the other return points.
Anyway, OOP guidelines of very short (7 +- 2) meaningful lines of code per method made this a moot point.
|
|
|
|
|
You could always do this as:
if (child != null && child.Parent != null && child.PrevNode != null)
{
}
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I sort of agree, but rather than:
MenuItemNode child = tvMenu.SelectedNode as MenuItemNode;
if (child == null)
return;
MenuItemNode parent = child.Parent as MenuItemNode;
if (parent == null)
return;
MenuItemNode swap = child.PrevNode as MenuItemNode;
if (swap == null)
return;
I would prefer:
MenuItemNode child = tvMenu.SelectedNode as MenuItemNode;
if (child == null)
{
return;
}
MenuItemNode parent = child.Parent as MenuItemNode;
if (parent == null)
{
return;
}
MenuItemNode swap = child.PrevNode as MenuItemNode;
if (swap == null)
{
return;
}
Just to remind me if I add a statement before the return.
|
|
|
|
|
EyeYamFedUp wrote: Public gblnSuperUser As Boolean
Public gblnLogonOK As Boolean = False
Wow. Excellent security paradigm.
|
|
|
|
|
What's your problem with it? He used comments didn't he?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: He used comments didn't he?
Indeed! Even the polished version ('* ).
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Programmer - an organism that turns coffee into software.
|
|
|
|
|
struct _X
{
int field1;
int field2;
int field3;
} anArray[15];
for (int i = 0; i < 15; ++i)
{
anArray[i].field1 = 1;
}
for (int i = 0; i < 15; ++i)
{
anArray[i].field2 = 2;
}
for (int i = 0; i < 15; ++i)
{
anArray[i].field3 = 3;
}
|
|
|
|
|
How horrible this is depends on the language: is it C? C++? something else?
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
It's C, but I don't see how the language makes it any better or worse.
|
|
|
|
|
some languages such as C# allow for code inside a struct; C does not. How would you do it in C?
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
No matter what language - all of them allow at least for summarizing this in one loop construct...
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Programmer - an organism that turns coffee into software.
|
|
|
|
|
right.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Exactly the point I was trying to make.
|
|
|
|
|
I don't know, maybe Brain f*** doesn't.
Cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
|
|
|
|