Coding Pet Peeves

[James [a_leon]]

Nov 23, 2010 11:46:33 GMT -8 BFD said:

Nov 17, 2010 15:01:04 GMT -8 Charles Stover said:

I hate brackets for one-line conditionals.

for (i=0;i<10;i++)
{
if (i%2==0)
alert("Even");
else
alert("Odd");
}

I also hate conditions when they can be inline.

for (i=0;i<10;i++)
alert(i % 2 ? "Odd" : "Even");

EDIT:
P.S. space after for and if

My peeve is that people people over-condense their code when it does not actually save a step during execution. Readibility is crucial when there is even a possibility you might need to turn code over to someone else for maintenance/enhancement. You also have to consider that often, the person maintianing code is not a proficient programmer.

Good documentation and comments in the coding takes away the need for readability from someone not "proficient". But come now, if someone isn't a proficient programmer, why are they maintaining it? Become more proficient or hire someone else.

Nov 23, 2010 11:46:33 GMT -8 BFD said:


IF @ysnProceed <> 0
       UPDATE tblData SET strDataField = 'CLEARED'




IF @ysnProceed <> 0
       BEGIN
    UPDATE tblData SET strDataField = 'CLEARED'
       END


If you later needed to add a delete of another table, a common mistake would be to change it as follows:


IF @ysnProceed <> 0
       UPDATE tblData SET strDataField = 'CLEARED'
       DELETE tblDataLog


This would result in a disasterous bug that will result in the second table being deleted regardless of the flag. If you always make it a habit to enclose the "then" clause in a begin/end block, it would be very difficult to make the above mistake.

You don't have to be a proficient programmer to know that when only a single operation is being done, it doesn't need to be wrapped. In fact, that's a pretty basic thing to know. If somebody doesn't know this, they shouldn't be the one maintaining or editing the code.

Nov 23, 2010 11:46:33 GMT -8 BFD said:

• Lack of comments

Lack of comments is the only reason why code shouldn't be condensed.

Nov 23, 2010 11:46:33 GMT -8 BFD said:

• Procedures/functions that span several hundred lines. Way back in the 90's while in college, it was drilled into our heads that you should be able to view a single function or procedure on your monitor screen without having to scroll. And that was in the days of text monitors that would only display 30 lines or so. While I think that standard is a bit impractical, I find that keeping to a single page of code per procedure is reasonable. If I notice I am approaching a full page, I usually can find areas that need to be factored out.

While I can see where this would be nice, I don't think it really matters anymore. Though I agree in the sense that most often it can be broken into smaller functions.

Nov 23, 2010 11:46:33 GMT -8 BFD said:

• Unnecessary cleverness. If you don't need to invoke an advanced language feature or complex programming technique, DON'T. If you are being paid to develope a program, you are being paid to make it work according to the specification and with a reasonable level of performance. Don't waste time trying to squeeze a few nanoseconds out of a routine that is going to be executed once or create an algorithm that while ingenious, cannot be debugged by an average programmer. The most brilliant programmer I have ever worked with was a master of making code extremely simple.
  

I have to disagree. If I'm being paid to develop something and I can produce something that runs with the smallest footprint (and therefore fastest speed), that's something I'm going to use to pitch myself over someone else. While at firs the code may not be able to be debugged, reading the documentation that's included would included everything needed to be able to understand the code.

[BFD]

Nov 29, 2010 11:40:40 GMT -8 James [a_leon] said:

Nov 23, 2010 11:46:33 GMT -8 BFD said:

My peeve is that people people over-condense their code when it does not actually save a step during execution. Readibility is crucial when there is even a possibility you might need to turn code over to someone else for maintenance/enhancement. You also have to consider that often, the person maintianing code is not a proficient programmer.

Good documentation and comments in the coding takes away the need for readability from someone not "proficient".
But come now, if someone isn't a proficient programmer, why are they maintaining it? Become more proficient or hire someone else.

Testing/Debug/Maintenance is a very common starting point for entry level programmers...in fact, most of the good programmers I have worked with over the years started out sorting through other people's code, figuring out how to fix small problems and making minor changes. It is an excellent way to learn good practices. And I have found that most of the time, when I am headed towards a complicated solution to a problem, I can take a step back and either find a better way or even worse, discover I am not solving the real problem.

You don't have to be a proficient programmer to know that when only a single operation is being done, it doesn't need to be wrapped. In fact, that's a pretty basic thing to know. If somebody doesn't know this, they shouldn't be the one maintaining or editing the code.

As long as the more verbose method doesn't affect performance, I am a strong proponent of using it. While it may take a few seconds more to type the extra statements, keep in mind that a line of code may be read dozens, even hundreds of times before its lifecycle is complete. In most development environments I have encountered, programmers are frequently moving from project to project, many in drastically different languages. If a few extra begin and end statements can make it a little quicker to get into the correct flow of an algorithm, don't be lazy and not type them.

Lack of comments is the only reason why code shouldn't be condensed.

If condensing doesn't save compiled lines of code or execution time, why sacrifice readability?

While I can see where this would be nice, I don't think it really matters anymore. Though I agree in the sense that most often it can be broken into smaller functions.

I will admit this rule doesn't necessarily apply to scripting/xml type languages - I don't do much html or CSS, but it is very difficult to keep asp and xaml file sizes to within a page. However, when developing the code behind, a full page of code is a classic sign you need to refactor.

Nov 23, 2010 11:46:33 GMT -8 BFD said:

• Unnecessary cleverness. If you don't need to invoke an advanced language feature or complex programming technique, DON'T. If you are being paid to develope a program, you are being paid to make it work according to the specification and with a reasonable level of performance. Don't waste time trying to squeeze a few nanoseconds out of a routine that is going to be executed once or create an algorithm that while ingenious, cannot be debugged by an average programmer. The most brilliant programmer I have ever worked with was a master of making code extremely simple.
  

I have to disagree. If I'm being paid to develop something and I can produce something that runs with the smallest footprint (and therefore fastest speed), that's something I'm going to use to pitch myself over someone else. While at firs the code may not be able to be debugged, reading the documentation that's included would included everything needed to be able to understand the code.

It isn't just about simplifying the code - it is about spending time the customer isn't willing to pay for or that could be better used elsewhere. I have also had customers reject quotes for significant application speed enhancements because they would rather spend the money on faster hardware that will boost performance across all their applications.

Please keep in mind that my peeves are based on 15+ years of developing database oriented business applications in a team environment, often for corporations with fairly large IT departments. I have also teamed with programmers with a wide range of abilities...everything from beginners to PhD's in Computer Science. What works in my sandbox might not work in yours.

[Charles Stover]

You have a rather flawed idea of the pros and cons of "clever" code.

I find:
document.write("it is " + (x ? "x" : "y"));
much easier to read than:
if (x)
{
document.write("it is x");
}
else
{
document.write("it is y");
}

I can also read and type it faster, which results in _saved_ time, not spent time.

I would also do it for the same price as someone doing the latter.

Also, clever code in web programming results in saved bandwidth, reduced HTTP requests, and reduced page loading times. These save the customer money for as long as the script is being used. Anyone who's serious about their website is going to want these features, even more than the equivalent cost in hardware (seeing as how the equivalent cost, while a lot on a per-project basis is not worth much in terms of server hardware).

You're essentially saying, why hire a programmer when you can make it using a Page Builder for free? Just buy more hardware to make up for the excessive bandwidth the Page Builder will use.

[BFD]

Dec 1, 2010 11:50:49 GMT -8 Charles Stover said:

You have a rather flawed idea of the pros and cons of "clever" code.

I find:
document.write("it is " + (x ? "x" : "y"));
much easier to read than:
if (x)
{
document.write("it is x");
}
else
{
document.write("it is y");
}

I can also read and type it faster, which results in _saved_ time, not spent time.

I would also do it for the same price as someone doing the latter.

Opinions vary, but I will reiterate my statement - by being verbose, you KNOW it will be obvious when read. I realize you want to keep your little website programs to yourself, so you don't care if someone else can read it. However, when building larger systems (that integrate web, desktop and service components) in a team environment, it does actually matter. Experience/proficiency on a project team is not going to be uniform for each member for all languages/platforms involved. There may even be entry level programmers involved.

I generally don't write ASP, but I do have a basic competency. My company (and the customer) pays dearly when I have to spend extra time figuring out how a page works so I can modify it just because the "web" expert at the time geared the comments towards his/her own level of expertise or got unnecessarily clever (emphasis on unnecessary). It isn't that I am the lesser programmer, it just isn't my area of expertise and the person who wrote the code is busy on another project.

As long as the optimizer brings the code to an equivalent performance/footprint, simpler is ALWAYS better, especially if the time spent is also comparable.

Also, clever code in web programming results in saved bandwidth, reduced HTTP requests, and reduced page loading times. These save the customer money for as long as the script is being used. Anyone who's serious about their website is going to want these features, even more than the equivalent cost in hardware (seeing as how the equivalent cost, while a lot on a per-project basis is not worth much in terms of server hardware).

One of the best measures of how good a progammer is, is the ability to identify when the fancy stuff actually matters. If your "clever" techniques actually makes an improvement, knock yourself out. Go for it. If leveraging a new language construct will make the code more intuitive or concise, go ahead. If your complicated algorithm has definite advantages, that's great. But if all it does is combine four lines of 60 characters into one 50 character line and compiles to the same thing, then it is a bad idea. If the new language feature doesn't buy you much and it jeapardizes portability, it should not be used.

I am not an expert in website development and am definitely not saying to ignore best practices. What I am getting at is, if it doesn't make a difference in the compiled, optimized code, keep it simple.

You're essentially saying, why hire a programmer when you can make it using a Page Builder for free? Just buy more hardware to make up for the excessive bandwidth the Page Builder will use.

No, that is not what I have said. But one of the key steps to moving from a programmer to a solution architect is to identify the most appropriate combination of off the shelf and custom software for the customers needs. While it may seem stupid to you, I have on several occaisions spent a few hours or days setting up customers to use off the shelf products such as Excel to solve problems when we could have proposed $30K+ developments projects. It may be a little slower or harder to use, but it solves the customers need for the lowest cost. That usually pays off in the long run by earning the customer's trust that we will always guide them to the best solution for their money. Granted, I have seen where other programmers have bilked customers out of small fortunes by just doing what they ask rather that figuring out what they actually needed...but that is not the way I (or my company) will operate.

[Charles Stover]

Dec 1, 2010 13:39:45 GMT -8 BFD said:

Dec 1, 2010 11:50:49 GMT -8 Charles Stover said:

You have a rather flawed idea of the pros and cons of "clever" code.

I find:
document.write("it is " + (x ? "x" : "y"));
much easier to read than:
if (x)
{
document.write("it is x");
}
else
{
document.write("it is y");
}

I can also read and type it faster, which results in _saved_ time, not spent time.

I would also do it for the same price as someone doing the latter.

Opinions vary, but I will reiterate my statement - by being verbose, you KNOW it will be obvious when read. I realize you want to keep your little website programs to yourself, so you don't care if someone else can read it. However, when building larger systems (that integrate web, desktop and service components) in a team environment, it does actually matter. Experience/proficiency on a project team is not going to be uniform for each member for all languages/platforms involved. There may even be entry level programmers involved.

Then that's a problem with the management. They shouldn't hire professionals and amateurs. In fact, they shouldn't even hire amateurs. That's the point of having professionals. If they're hiring amateurs with the idea that they'll be able to handle a large project with the proficiency that a professional can, that's bad management. If they're hiring professionals under the assumption that they'll dumb their programs down to a level an amateur can understand, that's bad management (and a waste of money).
No, there is no reason for a professional programmer to not code professionally.

I generally don't write ASP, but I do have a basic competency. My company (and the customer) pays dearly when I have to spend extra time figuring out how a page works so I can modify it just because the "web" expert at the time geared the comments towards his/her own level of expertise or got unnecessarily clever (emphasis on unnecessary). It isn't that I am the lesser programmer, it just isn't my area of expertise and the person who wrote the code is busy on another project.

You aren't a lesser programmer, but you are - as admitted - a lesser ASP programmer. They shouldn't hire you to do an ASP job, and I think it's hilarious that they pay you extra to do it. Your personal experiences really should have no baring on what is actually good business practice.

One of the best measures of how good a progammer is, is the ability to identify when the fancy stuff actually matters. If your "clever" techniques actually makes an improvement, knock yourself out. Go for it. If leveraging a new language construct will make the code more intuitive or concise, go ahead. If your complicated algorithm has definite advantages, that's great. But if all it does is combine four lines of 60 characters into one 50 character line and compiles to the same thing, then it is a bad idea. If the new language feature doesn't buy you much and it jeapardizes portability, it should not be used.

The entire point of "clever" code is that it has advantages. You can write an entire program on a single line and replace well_described variables with a single letter. Why would someone do that if it has no advantage? That isn't clever code. You said clever code is bad. What makes it clever is that it has advantages that are not otherwise obvious - such as caching, minimizing requests, or reducing bandwidth costs. That isn't the same as removing readability with absolutely no advantage.

[BFD]

Dec 1, 2010 15:34:00 GMT -8 Charles Stover said:

Dec 1, 2010 13:39:45 GMT -8 BFD said:

Opinions vary, but I will reiterate my statement - by being verbose, you KNOW it will be obvious when read. I realize you want to keep your little website programs to yourself, so you don't care if someone else can read it. However, when building larger systems (that integrate web, desktop and service components) in a team environment, it does actually matter. Experience/proficiency on a project team is not going to be uniform for each member for all languages/platforms involved. There may even be entry level programmers involved.

Then that's a problem with the management. They shouldn't hire professionals and amateurs. In fact, they shouldn't even hire amateurs. That's the point of having professionals. If they're hiring amateurs with the idea that they'll be able to handle a large project with the proficiency that a professional can, that's bad management. If they're hiring professionals under the assumption that they'll dumb their programs down to a level an amateur can understand, that's bad management (and a waste of money).
No, there is no reason for a professional programmer to not code professionally.

Where did the whole professional/amateur thing come from? And where do you get that I am advocating dumbing down or unprofessional practices? This whole discussion is leading me to believe you have never really worked in a professional, team environment on projects of significant size.

Simple economics dictates that you don't assign menial programming tasks to senior level developers. And yes, in the real world of software development, there are menial tasks. Granted, on small projects, it may seem like every detail is a big deal. It is also a matter of practicality that you have to tolerate programmers with lower levels of expertise...how else are they going to learn? And no one walks out of school an expert...it is foolish to believe so.

You aren't a lesser programmer, but you are - as admitted - a lesser ASP programmer. They shouldn't hire you to do an ASP job, and I think it's hilarious that they pay you extra to do it. Your personal experiences really should have no baring on what is actually good business practice.

Why shouldn't I make the modification? All it takes is a little bit of consideration on the part of the original developer. Writing code that is easily modified is a basic tenet of good programming...you should know that, the "professional" that you are. And I don't get paid extra. (another case of - where did you get that from)

One of the best measures of how good a progammer is, is the ability to identify when the fancy stuff actually matters. If your "clever" techniques actually makes an improvement, knock yourself out. Go for it. If leveraging a new language construct will make the code more intuitive or concise, go ahead. If your complicated algorithm has definite advantages, that's great. But if all it does is combine four lines of 60 characters into one 50 character line and compiles to the same thing, then it is a bad idea. If the new language feature doesn't buy you much and it jeapardizes portability, it should not be used.

The entire point of "clever" code is that it has advantages. You can write an entire program on a single line and replace well_described variables with a single letter. Why would someone do that if it has no advantage? That isn't clever code. You said clever code is bad. What makes it clever is that it has advantages that are not otherwise obvious - such as caching, minimizing requests, or reducing bandwidth costs. That isn't the same as removing readability with absolutely no advantage.

Did you even notice the quotes around "clever"?

I'm done...have fun being an "elite" programmer. I'll keep solving business problems.

[Charles Stover]

have fun being an "elite" programmer.

you have never really worked in a professional, team environment on projects of significant size.

you should know that, the "professional" that you are.

I'll keep solving business problems.

And I don't get paid extra. (another case of - where did you get that from)

My company (and the customer) pays dearly when I have to spend extra time figuring out how a page works

Paying for extra time is equivalent to extra pay.
You get paid to learn something you should already know before doing a job. That is a fault with your company, not the principle of whether or not to use professional code.

The whole conversation seems to revolve around the meaning of the word clever. I've provided many examples of "clever" codes; shorthand or optimized, they're things that an amateur wouldn't understand. Every one has an upside, and any person being paid to use the language should know how to do them (otherwise they shouldn't be hired in the first place, having no grasp of the language; and if they are, that's the fault of the company, not the principle).
Can you provide an example of "clever" code that shouldn't be used and why? Otherwise I'm debating against a vague notion of something that may not even exist, since you apparently are neither talking about professional nor optimized code. I'm not aware of any other way to interpret "clever" code in a negative manner in which it would still be clever.

And I can't stress enough "so that the company can hire someone who isn't even familiar with or only has a basic grasp of the language to edit the code" isn't even remotely a good reason. That's like saying we should only write novels on a 3rd grade level so that foreigners can more easily read them. The target audience is the average reader (a programmer fluent in the language), not a potential minority reader who shouldn't be reading it in the first place (a database designer writing ASP).

[Jordan]

Charles, the basic idea is to write code that can be easily modified later. Keeping the code clean and clear but efficient is the key. When you work on big projects in the industry there's a lot of code that you have to comprehend, and things can get a lot more complicated in real programs when you are having to communicate with the operating systems to manage resources. Small optimizations are not always necessary, especially with modern compilers and computers. If you really want that much optimization you should drop down to assembly, but even then a C++ compiler may do just as good. Seriously though, have you ever done any real programming in a language like C++ where you are dealing with pointers and dynamic memory? It's easy to make mistakes, especially when you are modifying code written by someone else.

[BFD]

Even though I said I was done, I would like to add another peeve - avoid using negative logic!

I just opened a desktop app we wrote years ago using C# and found the following:


               if (frmPayment.blnRewriteLoan == false)
               {
                   userCtlLoanPrimary.AdjustmentLbl.Visible = false;
   ...
                   userCtlLoanPrimary.ReWriteExpenseTxtBx.Width = 0;
               }
               else
               {
                   EnableDisableLoanPanelControl(true);
                   userCtlLoanPrimary.AdjustmentLbl.Visible = true;
   ...
                   apnlSalesInfo.Expand();
                   apnlTradeIn.Compress();
                   apnlFees.Compress();
               }

While the above line of code is harmless, starting with a simple negative logic statement can snowball into a real mess...especially when you introduce boolean variables that are used later in the code.

Dec 2, 2010 11:05:20 GMT -8 Charles Stover said:

have fun being an "elite" programmer.

My company (and the customer) pays dearly when I have to spend extra time figuring out how a page works

Paying for extra time is equivalent to extra pay.
You get paid to learn something you should already know before doing a job. That is a fault with your company, not the principle of whether or not to use professional code.

The whole conversation seems to revolve around the meaning of the word clever. I've provided many examples of "clever" codes; shorthand or optimized, they're things that an amateur wouldn't understand. Every one has an upside, and any person being paid to use the language should know how to do them (otherwise they shouldn't be hired in the first place, having no grasp of the language; and if they are, that's the fault of the company, not the principle).
Can you provide an example of "clever" code that shouldn't be used and why? Otherwise I'm debating against a vague notion of something that may not even exist, since you apparently are neither talking about professional nor optimized code. I'm not aware of any other way to interpret "clever" code in a negative manner in which it would still be clever.

Yes, we have been twisting around our interpretation of the word...and I imagine a lot of the nitpicking we have done is senseless...we probably would be in agreement if we started talking about the same thing.

To put things back in context, here is my original peeve:

Unnecessary cleverness. If you don't need to invoke an advanced language feature or complex programming technique, DON'T. If you are being paid to develope a program, you are being paid to make it work according to the specification and with a reasonable level of performance. Don't waste time trying to squeeze a few nanoseconds out of a routine that is going to be executed once or create an algorithm that while ingenious, cannot be debugged by an average programmer. The most brilliant programmer I have ever worked with was a master of making code extremely simple.

I still stand by it.

As for examples, here are a few:
The task: Create an invoicing function in MS Access that generates an invoice number as the existing invoice report was sent to the printer. One of my coworkers put event handlers on the report rendering events that generated the invoice number in an early event, then in a later event marked the shipment record as having been successfully invoiced. If printing failed, it would even roll back the advanced invoice number if possible. It was a nice, clever solution. However, the customer really didn't care about keeping the invoice number sequence and didn't mind answering a dialog box that asked if the invoices printed correctly (at that point, the invoiced flag would be set). My coworker even considered using a dialog box, but rejected it because it wasn't elegant enough for his standards. And by the way, we eventually migrated to the dialog box approach as the customer experienced intermittent printer failures that were not communicated back to Access.

Unique ID/Sequence number generation: I have seen so many ingenious ways to generate unique strings and sequential numbers, both in code and at the database level. At times they are necessary - most companies don't like having gaps in receipt or invoice numbers...but most of the time, the built in sequential number generator will meet the needs.

You might remember this thread:
support.proboards.com/index.cgi?action=display&board=programming&thread=348415&page=1
I am fairly certain the programmer who wrote this thought it was very clever.

I will probably think of others, but I think you get the point. They aren't good code or the ideal method for solving the problem, just unnecessarily complex and in some cases, actually clever. Most of them are written by "eager puppies" who want to impress with complicated code and lose sight of the most basic instruction in many fields - Keep It Simple Stupid.

You could also say I am advocating a form of Occams razor - when presented with two equally effective programming solutions, always take the simpler one.

And I can't stress enough "so that the company can hire someone who isn't even familiar with or only has a basic grasp of the language to edit the code" isn't even remotely a good reason. That's like saying we should only write novels on a 3rd grade level so that foreigners can more easily read them. The target audience is the average reader (a programmer fluent in the language), not a potential minority reader who shouldn't be reading it in the first place (a database designer writing ASP).

So...is the reverse true? Should you be calling me to create all your tables? (just kidding).

Not every job requires an expert. While I wouldn't tackle an e-commerce site, I have turned out a few ASP.net sites that fully meet my customers' needs. They aren't perfect, but didn't need to be. Just because I may take longer, it doesn't mean I can't and in many situations, shouldn't. My expertise as a database developer has saved more than one ASP project and I do not hesitate to bring in the non-expert opinion.

You also have to keep in mind there is no set watermark for becoming an "expert" or "professional" programmer (actually, by most definitions, you are a technically "professional" as soon as you get paid). Most programmers I know (including myself) spent their first few months or years in the industry testing and debugging under supervision of an experienced programmer. While only vaguely familiar with the language and good programming practices, we got the job done and didn't cost a whole lot while doing it. I am sure you didn't just take off out of school writing brilliant code...it just doesn't happen. Schools and training classes may teach you a language and the basics of programming, but writing real world applications and working with more advanced programmers is how most people become truly proficient.

Before you go off on another rant about allowing for the incompetent, I am NOT saying to hire non-programmers to program as experts. On decent sized projects, there are tasks that can be completed by a wide range of abilities and when you are a senior member in such an environment, you work accordingly - comment like crazy, which isn't a bad idea in the first place. If you have ever worked on a decent sized project team, you would know this.

[Charles Stover]

Dec 2, 2010 19:00:18 GMT -8 Jordan said:

Charles, the basic idea is to write code that can be easily modified later. Keeping the code clean and clear but efficient is the key. When you work on big projects in the industry there's a lot of code that you have to comprehend, and things can get a lot more complicated in real programs when you are having to communicate with the operating systems to manage resources. Small optimizations are not always necessary, especially with modern compilers and computers. If you really want that much optimization you should drop down to assembly, but even then a C++ compiler may do just as good. Seriously though, have you ever done any real programming in a language like C++ where you are dealing with pointers and dynamic memory? It's easy to make mistakes, especially when you are modifying code written by someone else.

I'm a web programmer, so I don't use C++. There is surely a large difference in what "clever" code does in the two types of languages.

But, again, there hasn't been an example of "clever" code of which to comment on the cleverness or necessity.

[Charles Stover]

Dec 3, 2010 12:31:49 GMT -8 BFD said:

Yes, we have been twisting around our interpretation of the word...and I imagine a lot of the nitpicking we have done is senseless...we probably would be in agreement if we started talking about the same thing.

To put things back in context, here is my original peeve:

I still stand by it.

As for examples, here are a few:
The task: Create an invoicing function in MS Access that generates an invoice number as the existing invoice report was sent to the printer. One of my coworkers put event handlers on the report rendering events that generated the invoice number in an early event, then in a later event marked the shipment record as having been successfully invoiced. If printing failed, it would even roll back the advanced invoice number if possible. It was a nice, clever solution. However, the customer really didn't care about keeping the invoice number sequence and didn't mind answering a dialog box that asked if the invoices printed correctly (at that point, the invoiced flag would be set). My coworker even considered using a dialog box, but rejected it because it wasn't elegant enough for his standards. And by the way, we eventually migrated to the dialog box approach as the customer experienced intermittent printer failures that were not communicated back to Access.

Unique ID/Sequence number generation: I have seen so many ingenious ways to generate unique strings and sequential numbers, both in code and at the database level. At times they are necessary - most companies don't like having gaps in receipt or invoice numbers...but most of the time, the built in sequential number generator will meet the needs.

You might remember this thread:
support.proboards.com/index.cgi?action=display&board=programming&thread=348415&page=1
I am fairly certain the programmer who wrote this thought it was very clever.

As I said in that topic [and in my second to last post], I don't consider that clever. It's not easy (I guess that makes it clever?), but it serves no purpose. It optimizes nothing.

They aren't good code or the ideal method for solving the problem,

I wouldn't consider anything that's not the ideal method of solving the problem to be clever. Hence my saying clever code should be used. If it improves on anything, even at a loss of readability (such as using single quotes instead of double quotes in PHP, even for strings that contain single quotes, to decrease parse time), it's clever. A good example would be assigning unique numerical IDs in a database to each user and using that ID to reference the user from other tables, as opposed to a string reference. It makes references a tad more complicated, but it improves reading speeds and database size almost immeasurably. I wouldn't, on the other hand, consider a unique CHAR(3) ID as clever, even though it will still the decrease database size of a table that didn't previously contain a numerical ID, because it is not ideal. Like your link to the previous topic, I think it would be the opposite of clever in that they are missing what is right in front of their face. They know a shorter unique ID should be used, but they can't determine that numbers are smaller than strings.

So no, useless or unideal complexity should never be used. Of course I would agree to that. But I wouldn't call it clever, for sure.