tags:

views:

answers:

Maybe infuriate is not the politically correct term, but what kind of code would qualify for a genuine face palm?

Addendum:
For me, it's the misuse of technology. The group of people who develop .NET like classic asp apps are very likely the same group of people who use recursion for simple iteration, standard array where linked list is blatantly the answer, massive number of individual variables in combination with if-statements for hash tables, functions for properties, validating input forms with only javascript, placing important naked-eye readable information in cookie,and on and on and on....

+8 A:

Right now? Large amounts of CPP files with only 1 H file for the entire project.

Agreed. I recently started looking at some old cpp code with a header file took me about an hour to look through. It could have easily been split up into four or five files to make more sense. The bad part was, it was code that I wrote.

he's right tho, it's not just loop indents and the like, it's separating you code within functions into logical blocks space spaced and commented if appropriate - that can't be done automatically - you need to understand what the code is doing

@Bill K: The problem comes when the section of code in question have generated tens of bugs. If you ctrl-shift-F it, you will be winning the raffle of the tiger ( does that saying exists out of where I live ) I mean, the VCS will give you the paternity of such code. :S :S

I hate opening a file just to see 50 collapsed regions, each of which containing another 50 collapsed regions. It's bad enough I have to dig through the object hierarchy, but now I have to dig through the region hierarchy the developer came up with!

Yes, that is always an option and you can always ignore the #Region ""and #End Region lines. However, modifying that file is still difficult since any changes you make have to fall into the correct region. Otherwise the code becomes even messier. :-)

I actually like regions if it's well defined. If your company has a standard policy of collapsing class fields, properties, event handlers, ETC, it can be very convenient and time-saving. But like all other tools, it can be abused.

Frankly I see not why you would have to use a language feature for the presentation of code. THis is context bleed, much like putting the styling in HTML. Code styling belongs to the IDE, I have enough of programming the system I cannot be bothered with programming the IDE through the code.

Yes they are awful, especially because everybody uses them to their liking. More times then not, if you got really lots of region, it suggests lower cohesion within that class, so refactor that code man!

You can't trust anything in inconsistent code. Even if the previous developer used conventions and techniques that make me wince in pain, if he was consistent about it I can at least learn to identify with my torturer. Inconsistent developers deny me even that faint comfort.

You can't really trust anything in consistent code either, mind you. But it's one thing to be able read code like a programmer, and another thing entirely to have to read it like a compiler or interpreter.

@Bill... Totally agree with you, nothing I like more than a new clever way to tackle a problem, but sometimes they can get a little too creative. Mix a bit of the Onion (my favorite antipattern) with that and you get masochist pure joy

You don't want to cut off after a couple hundred lines--there are a *FEW* cases where it's reasonable. All of them at their heart involve a large switch statement or equivalent. (I've hit it with a massive if..then..else.if..then that was really a switch but the key was a string and Delphi doesn't do strings in case statements.)

my biggest beef here is not so much that the if statement was big but that the whole program was a main function. No class, no struct no sub function nothing... start the main... start coding and close main.. that's it. craazy

@monoxide: I have seen such a method where that 'tmp' variable was not just used and reused, but redefined in an inner scope and used again. Trying to find out what the code was doing, just by looking at it was impossible.

Usally I take a deep breath and say.. Ok, I'm going to wear my "Refactorer hat" and fix it. By the 3rd hour of not getting anything done, and not have a clue where to start, I go to the line 756 and add another cryptic if then else, test and verify the bug is gone and close the editor. :( :(

Code where someone undisciplined decided that they had to do things their way (usually because it is the ONLY way according to them) instead of sticking with the convention that the code already had going. Then you have to sift through all the different styles.

I just got done maintaining some database code and the guy just did not understand the concept of working with sets of data. EVERYTHING was single row actions, looping through using cursors. There were no multi-row updates, just a cursors looping through updating each and every row.... That was just a recent example.

So in a nutshell, developers not understanding the type of system they are working with and writing appropriate code.

That's right, SM... I agree [I remember having taken this to extreme as I used to have spaces in my column names in MS-Access like "Customer Name"... I used to say customerRecords![Customer Name] in VB to access the same..Eons ago! (sigh)]...I cry when I see names like "Cust_Name" and "tblCustomers"

Well it also depends on whether or not the language has short circuit evaluation. If the language (*cough* VB *cough*) doesn't, then your code will perform better if you don't evaluate multiple conditions in an if. You either need to do each condition, or throw it into a Select Case.

Vilon, I understand Middle Men are useful to, for instance, Hide Delegate. But I've seen cases at my workplace where *every* method in class A calls a near-identically-named method in class B. In that case, I have class B implement the same interface that class A does, and delete class A.

Bill, I totally agree. I think a big reason people, including myself up until fairly recently, don't get it is because methods in popular OO languages (read: Java, C++) look way too much like functions in procedural languages. Merely reading about Smalltalk made it all click for me.

It's very unfortunate that Sun decided to implement beans the way they did. Beans should be pure data transfer constructs with no code associated with them at all (if all they are are setters and getters). If you want to add code, wrap a class around it...

I just hate it when I come over some internal implementation of functionality which is in fact part of the platform.
And no one has a real clue about why it was implemented that way, and not used the existing platform implementation.
Especially when the internal implementation is a sub set of what is provided by the platform.

I have been forced to reinvent things in current JDK versions because we have to target old JVMs - I only recently got to begin targeting Java 1.3 in my work; and I am having to push mighty hard to be allowed 1.4... what I wouldn't give for 1.6!

Excessive "wiring", where some idiot developer got so jazzed about eliminating "dependencies" that none of the classes actually refer to each other, and everything is hooked together in an enormous XML file.

Reading the code, you can't actually tell how anything works anymore, because the ordinary flow of logic is obfuscated until runtime, when all the functionality is magically woven together by some over-architected framework.

Yeah, sure, you can ALT-TAB back and forth between the code and the XML and try to remember how all the classes are wired together.

But first, you should walk down the hall and punch that jackass in the teeth.

ON EDIT:

Incidentally, I'm familiar with the DI and IoC patterns, and I'm perfectly happy to admit that they're occasionally useful. In fact, if I may be so bold as to quote Martin Fowler:

Inversion of control is a common
feature of frameworks, but it's
something that comes at a price. It
tends to be hard to understand and
leads to problems when you are trying
to debug. So on the whole I prefer to
avoid it unless I need it. This isn't
to say it's a bad thing, just that I
think it needs to justify itself over
the more straightforward alternative.

There have been certain (rare) cases when I've happily used DI. But only under these circumstances:

When you actually have multiple implementations of a service, AND

When the selection of those services must be applied at configuration time (not at compile time or runtime)

In my experience, this combination is extremely rare. Most projects I've been involved with have exactly zero justification for the injection of any dependencies. Sometimes there's a legitimate need, and yeah, in those cases DI is a lifesaver, because there's really no other way to do it.

But I can't tell you how often I've worked on a project with hundreds of service interfaces, each of which has one class implementing that interface. And then there's a configuration file with thousands of lines of XML to connect each service interface with its implementation and to inject constructors into every single private field.

That's IoC+ Dependency Injection. It can solve some HUGE problems. Sounds like you're upset because the tooling isn't able to handle it. Try testing in the debugger so you can see what an instance actually is. What you described is fantastic code except for the tooling issue.

I agree the tools suck since you are combining XML with Java at runtime to figure out what you're debugging, but that doesn't have to be the way. Debuggers will know the actual type, and I've been known to print the .getClass() name to see what instance is there at runtime.

No, Bill, this has nothing to do with tooling. The thing that annoys me is the developers who think IoC should be used *everywhere*. Sure, DI can occasionally solve some of those HUGE problems you refer to. But when mis-applied (more often than not) it CREATES huge problems.

Quite frankly IoC is interesting because it is easier to do mocking to test code. However, you got a point - it sure is harder to read code developed this way - I use multiple monitors and notepad+ to use the XML as a reference (1st monitor) code in the IDE(2nd monitor) and interface (3rd monitor)

Too many classes that don't do anything. On one project that I inherited, I found a pair of classes named "And.cs" and "Or.cs". The And class added " AND " to the end of a string, and the Or class added " OR ". They were used for building dynamic SQL.

I've used something like this because you could drop the class into a system and use it progmatically. For instance, a user can press the "AND" button on a GUI and it drops the "AND" appender into some collection and is later used to automate request building. I'm guessing that's not what you saw.

Any code that makes me guess, which means that I'm happy with pretty much anything I'm allowed to refactor or rewrite; and I'm fairly unhappy when there are pieces I can't rewrite.

I can only really understand a group of code by getting it all into my head. Code that's really poorly factored is very hard to get your head around. As you refactor and eliminate 2/3 to 9/10 of the code, it all becomes much more understandable--and the process is fun.

When I'm not allowed to refactor it, it can be difficult to impossible for me to work on it because I can't stand guessing. I don't just poke a variable and retest to see what happens, then if it happens to pass the test call it "Fixed" (which is what it seems like most people do).

It's not that I have anything against other people just kinda guessing and poking stuff in and seeing how it reacts, I'm just a bad guesser.

Code written by someone who hasn't taken the time to learn the language and any standard libraries. For example (and this is by someone I know), using arrays and array.resize to store a list of objects rather than std::vector or Generic.List. Not taking advantage of OO and type safety when using OO languages (someone else I know didn't use the class keyword anywhere in their C++ application, did use try/catch though).

Well, more than enough people use the `class` keyword because they saw it in a book and don't want to be seen as ignorant..

2009-03-15 13:51:24

+8 A:

The codebase I'm working on now was originated by someone who clearly never decided whether to use spaces or tabs for indentation - so they used both, completely inconsistently, often on the same line.

Sure, this project has just about every other anti-pattern you've ever heard of, but finding another line indented with "space-space-tab-space-tab-tab-space" is what really sets my teeth on edge.

(I finally started re-formatting every code file whenever I touched it, and I've got a chart on my office wall of which pages have been "fixed.")

This usually happens to me by accident when a file is edited in different editors. Some use actual tabs, and others insert x spaces instead of tabs, where x varies. That can make things fun, as you described.

For example, a stack is a stack. It is not an array. It is not a linked list. It is an abstract data structure that is to be accessed using the defined interface, not by directly accessing the implementation details. What bothers me is, for example, code not in the stack implementation that "knows" the stack is "really just a linked list" and accesses it as such.

Doesn't *** indicate a dynamically allocated 3-dimension array? How else would you implement that in C? Also--I occasionally put my initials in a method to remind me to change it once it's "Solid". Don't think I ever let one escape, but I've been sloppy before :)

In my younger, more vengeful, days, I was once irritated by a colleague who declined to fix a trivial bug that I had reported. It was a very quick flicker of the fields in the GUI when items changed.

The bug was bothering me because it showed the potential of being a serious flaw in the logic, but no-one else cared because the final output was still correct and the unit tests were passing. Eventually the team leader assigned the bug to me to fix just to shut me up.

So, I may have been a bit grumpy as I looked through his code for the bug, I had my red pen out and my notebook ready, to jot down every problem I found with his code, every potential bug, every confusing variable name, every inefficient loop, every violation of the coding standard.

His code was... immaculate. Well commented, well abstracted, good variable names, correct use of language features. It was probably the cleanest code I had ever seen in that organisation. It was flawless.

HOW INFURIATING!

p.s. When I eventually found the bug, it turned out to be trivial in its impact. There was no serious underlying logic flaw, and no-one cared that it had been fixed.

Implicit Code !!!! - The one design flaw or mistake that most programmers make is to have implicit "you just have to know code". a programmers assumptions are baked into the code. This is why pairing, code reviews, etc are needed . .someone programming alone can do lots of damage . . .

Classes with multiple responsibilities - The second is classes that have multiple responsibilities. People who code without unit tests often evolve into multiple responsibility classes that are coupled and hard to maintain.

People who stick to the framework's way of doing things, even when it's not the best/easiest way of doing things. A lot of times you are trying to do things the framework didn't anticipate, so you end up doing tons of hacks just to get things to work right. When really, if you just forgot about the framework, you could have done everything much easier. This is kind of a counter point against

people who develop .NET like classic
asp apps

People who just blindly follow the framework, and don't look at what the best solution is to solve their problem. In almost every instance where I've used ASP.Net, I've never used the webcontrols and viewstate tools that are provided by Microsoft.

Frame works are designed in a certain way, chances are that if you understand and follow the philosophy throughout your projects, it will give you a smooth development process. It comes down to consistency, I guess. When you don't use existing components, you might be reinvent the wheel anyways.

What irritates me most about maintaining other's code is when they have a unified framework for certain specific code, like form output in a CGI application, and then use the standard output buffer to instead make custom output. When restyling or looking for code that breaks, this exception to the status-quo is always the trouble. And whenever the HTML markup or stylesheet changes, every exception must be checked for consistency.

Poorly formatted code is definitely up there. I've been having to deal with dynamic SQL producing stored procedures and everything is collapsed and left-justified so it is REAL hard to find all the joins and relationships in a hurry.

Inconsistent code is probably my next ulcer inducer. Ok, I understand if you have too many cooks in the kitchen, you're bound to run into variations and different points of view. Fine, I get it. But when you have something like a CMS and everything is CRUD, and you already have say 10 resources within the same project, 100 resources from another project you could copy/modify, was it really necessary to engineer new code? Sure, I'd love to do things right all the time too, but when you have limited time and funding, "git 'r done" is acceptable.

All time favorite, "New tool syndrome". I forget the exact wording, but whenever a developer reads an article online, say, about Ajax and how you can generate dropdowns, now suddenly, EVERY dropdown on the site is done in Ajax... even a boolean True/False.

Or the person who never actually learned the language they are working in, and ask me how to determine a way to remove add/remove commas to make a string list proper, when the system already provides a ListAdd, ListDelete... /palmface

Being borderline evangelical about accessibility, semantic markup, easily readable script and well grouped style information, spaghetti code that mashes content, design and interaction together drives me up a wall. Things like DOM id's and classes that better describe what something looks like rather than what something is. Stuff that locks you into the design. I do realize this is more my issue and neurosis than anyone else's thing, but I really don't want to give up that bit of elitism.

People creating several versions of the same file and only using one. All with completely irrelevant names.

We have a php page that tracks emails called default.php. We also have stuff.php and crap.php that do the exact same thing. I spent 2 weeks debugging the wrong one of course thinking it was the right one.

Note: the unprofessionalism of all this is due to all of this being done by interns. Me being one of them. But even I know the value of naming files appropriately.

Aha-code or code you have to be clever to follow. It may look like you're incrementing a counter but in reality you're removing objects from a collection while accumlating a register or something stoopid. I'm to tired to post an exampke but you know what it's like when you hit AHA code.

Then there's the NIH (Not Invented Here) fanatic that wants to re-implement everything from the lowest level because Java regex is broken, or because we can save 4 bytes if we roll our own gzip algorithm.

Also I can't stand static references and tightly coupled logic that encourages copy/paste. When you see a method body a page or so long then you can't use the method anywhere that the stars aren't aligned. You make a change to the callee and it breaks everywhere. You try to break it into a separate project but then you realize you have to port all of it's dependencies as well even if they won't be used in your particular use case.

The thing I hate the most is when the delivered code does not work as promised - when it should implement a certain functionality but only the most basic paths of execution are covered.

This infuriates me because I know that what has been implemented is generally the tip of the iceberg and I know I have to implement the rest of it (and people who are aoutside of the project will think I'm just loittering with code instead of delivering real functionality).

Having to correct a bug in a "shared" component.

And by "shared", I mean "shared" as in "Hey, everyone touch this component and add his/her prefered feature to it."

It has an orgy-like smell that makes me gag everytime I have to delve into a less than stellar code which grew by random iteration and patching without a clear vision of what it was supposed to do ("specifications are not mandatory, you know").

You know, the kind of code where there are more ifs and switchs than variables and functions. The kind of code proving that a code quality of a component is of the level of the less skilled developer that once contributed to it. The kind of code that makes your eyes cry tears of blood, and wonder if you should not become Serial Killer instead of Developer...

Because, when you "touch" this kind of code, your greatest wish is to have it work the same way as before but for your little corner case (thus, you add a bunch of ifs atop a mountain of ifs).

Because your worst nightmare is to have a bug assigned to you because you were the last one to modify the code. Or even to look at the source. Or even, to use the component (This is the moment you lose your innocence).

Having to correct a bug in an unmaintained "Core Component"

In "our" team, we have a bunch of in-house developments. Like Joel Spolsky said, "if a module is the core of your business, then do it yourself". Apparently, everything in my team is the core of the business.

To make the taste more spicy, until recently, everything was developed using Win32 API (again, we can't trust MFC or whatever amateurish external library like QT).

So far so good...

But mix it with the "shared" philosophy mentioned above, and the fact that the author of the component did quit years ago and that no one is now (or feels now) responsible of the component.

you know, the naive faith of some non-technical managers about the fact developers are interchangeable monkeys...?

Welcome to the zoo... (Real life example)

This is a real-life example. It happened this week, in fact (truth to be told, it is a real core component, which adds its own perversion to the subject).

In the current case, one year ago, I mentioned the fact we would lose less time by using already existing libraries. The counter argument used was that we did not control the code of external libraries, nor the speed of their bugs correction, and thus, it was better to have our own code, as we could always correct any bug when needed.

Some days after (destiny has its own sense of irony), I discovered one of the core components had such a bug. This bug was serious, but it would only express itself in some corner case situation. They tried to assign its correction to me, but as I was overbooked (Lucky me!), no way I would spend days or weeks in 20,000 lines of old C code using obscure Win32 API functions you don't want to know they exist.

One year after, and guess what, the bug was still there. So much for the "Hey, we develop in-house because we can correct it fast."

"the naive faith of some non-technical managers about the fact developers are interchangeable monkeys...?" Says it all. The big question being why do we allow our team to let the code-base become a monkey-code-base?

And I despise over-architecting. My last job was working on a large, years-old, conglomerate system that exemplified every bad practice I'd ever read about. It was spaghetti code in the pure sense.

My current job is working on a system that was designed by a self-proclaimed guru who over-architected everything, rewrote major portions of the .NET Framework because he "knew better than Microsoft", and completely ignored decades of advancement in database theory.

I am constantly longing for that old spaghetti-code system. It was at least grokable.

From my current project: Where the (C++) coder gets embarrassed about the huge class he's writing and decides to 'refactor' by cutting and pasting the member functions into 13 different source files. Corollary: When the same coder, confident now, applies the same technique to the other bloated classes in the system, so that one source file may contain fragments of three different classes.

Took me days to find out that my plugin was throwing an exception every once in a while, because the exception got caught and written to some logfile in some obscure directory somewhere in the project...

Unnecessary abstraction. I think some people feel the need to apply every OO design pattern to every problem and encapsulate everything, regardless of how unlikely it is to change. Abstraction always comes at the price of making the implementation more difficult to understand, if you need to reason about its performance, fix a bug in it, etc.

The problem isn't the heavy application of design patterns, it's the GRATUITOUS application of them. I wrote some code recently uses six major patterns in 300 lines of code without being particularly abstract. I didn't expressly choose to use patterns, I noticed them after the fact.

Similar to some of the above posts, not understanding the technology used is a real problem. I had to work on one outsourced system that was where the code could've been straight C, but was proudly claimed to be C++ by nothing more that changing the file extension!

Trying to get these clowns to use the STL was also quite an eye opener, their idea of using an STL map was to copy the STL map header file, then go and hack their copy of the header file to contain the data types they wanted!

2008-10-25 18:38:00

+5 A:

CoWorkers who still use .net as if it was vb6. IE. just about all code in the form load and behind button_click events and hardly using classes :(.

I agree 100%, with the caveat that the above function should still exist if the combined functionality is needed often (especially if both operations take parameters). It should be implemented as calling the two separate functions.

Code with no documentation, no one at the company knows who wrote the code or when, it doesn't exist in source control, and some end user is complaining about something changing between yesterday and today without saying that they are using different parts of an application where the whole thing may have been broken for a long time.

In java, useless interfaces. I'm working on something now where someone thought, a few years back, that everything should have an interface. There are probably a good 100 or so pointless interfaces that only have 1 implementation. There was never any real need for it, someone thought it was good style.

Extra points for misuse of spring dependency injection, so all you have is a reference to something whose semantic meaning has disappeared. So anytime you want to trace you have to trace to the config, find out what they're actually using, figure out where the implementation is.

Project actually has a front end to a properties file that has a hard-coded getter for every property, and an interface to the hard-coded functions in the getter. So there's a good thousand lines of code to read properties, spread through property files, an interface and an implementation.

God, yes. In particular: making Hibernate beans implement interfaces. A persistent bean is not a service. It is a bean. The stuff you have to do to add generic declarations to things reveals what a bad idea this is.

Goto's: fall into this category too! Mostly for their tendency to create the most dreadful spaghetti-code.

Non-descriptive variable/function names: Really! Don't abbreviate & comment it. I don't want a lookup table. That's what the name is for in the first place! The point of code is to communicate effectively with other humans. Binary is for machines.

Abbreviations in variable/function names: You know what they mean. Nobody else does. (Bonus points if they are in your native tongue, and nobody else on the team speaks it!)

Unrolling Loops: Trust me, the compiler is better at this than you are. You are just going to introduce some really painful bugs!

Excessive Complexity: If you have 20 lines that start out "foo(...).bar(...).charlie(...).delta(...).echo(...).", then for gods sake use a reference or a macro to make the code human-readable.

Lack of discernible design: If I can't tell what you are doing, this is not going to go well. Put some UML in the comments! Document!

Multiple names for the same concept: Use xColumnWidth and yRowHeight if you have to. But don't use (x,y) for one method, (column,row) for another, and (width,height) for yet a third! (Bonus points if you reversed the order between methods, mixing (x,y) and (row,column).)

Cut & Paste coding: Really! Others have said this too and I'll say it again! Don't put the same broken chunk of code in 10 different places. Some day, I'm going to have to fix that. Or maybe just change it. Use a macro or a static function!

Shadowing variables: 'Nuff said.

Fixing compiler warnings by commenting out -Wall in the makefile: Me, you, and Mr. Bat need to have a little talk!

Lack of comments: If you are going to put some hairy piece of math into the code, document where it came from! At some point I'm going to have to fix it! (I know, I'm hitting commenting twice. But it's important! Especially when your pulling math out of a book or matlab. (Just give me a prayer of a chance here! That's all I need!)

Checking in broken code: Just because it compiles doesn't mean you are done!

Core leaks: This is going to come back to haunt us... Or, more precisely, me!

Along with the other great comments ('clever code', over complicating simple tasks, etc), it 'infuriates' me when the other C# developers (with 7+ years experience over me) don't understand my confusion trying to understand their code structure.
For example, single files stored in a deep hierarchical folder structure
C:\VisualStudio\WebSites\OurSite\Common\Products\Data\DataSources\Db\SQLServer\SqlServerDataSource.cs

Nearly every file is configured that way (and each project has an identical Data\DataSources\DB\SqlServer folder) with similar 5+ level namespace hierarchy (which doesn't match the folder structure)

Why not simply \AssemblyProject\MyClassFile.cs? Files easy to find, easy to maintain..why so complicated?

When I get to that level of experience (I have over 13 years of Delphi development experience, other developers are from different backgrounds, come from different companies and all have the same mindset)..will I start 'thinking' like that? Will I loose the K.I.S.S. way of doing things? I hope not.

I totally feel the misuse of technology. All stemming from a lack of caring and failure to improve. When a brain becomes stagnant, and I can tell by reading your code, it is a sad day.

2009-03-15 15:03:54

A:

I've had to do a lot of this recently, so I'll be honest.

Variables declared at the top of the function, uninitialized, in C-style C++ code. This hasn't been required for years and has no benefits, especially if you're not initializing them. It's redundant and pretty much asks for unused variables if the compiler warnings for that aren't turned on. Restricting the definitions to the smallest scope necessary can make odd logic flow in the function more obvious. It's a good change that was made in C99 and C++, and should replace the old method.

Uncommented, illogical program flow. Often I see pointless infinite loops, gotos, and longjmps all over the code that make no real sense. They all serve a purpose, but if you can't write complex program logic in a way that makes sense, you should at least comment it.

1- functions that passes implementation to others functions for no reason
2- Long 1k > codes that soar your eye
3- Missing dataflow and logic
4- Code written by some1 who never had a programming language and started with html design tool
5- Code the uses includes of chunk of code from different files as opposed to functions calls
6- Highly coupled codes

2009-05-19 17:44:19

A:

Commenting out large bodies of code using something like if(0) {...}. I read the whole thing, figure it out a bit and then see the if block. It didn't help that the 'commented out' block was not indented either.

I very much dislike it when I find that a developer has reinvented the wheel in the sense that a perfectly good library (or the platform itself) offers the functionality required. For example, I have seem developers write their own XML parsers, ArrayList (which had much worse performance), diff system, and database library (for working with databases).

Anecdote, from today. I have to refactor a small module that uses a class that is a direct copy of another class from the API of the CMS we program against. Comments only indicate where it's used (not what it does, mind), and I have to fix it because else the module will not be certified.

Next time you copy a class from the API, please indicate /why/ you copied it, so you don't waste my time.

Second, people that don't read what should be done. Same certification thing, the first round fails, the certifier says "You need to fix this problem, which happens (for example) in this bit of code. You could (for example) fix it like so-and-so".

But what happens, the guy that has to fix it (I just coordinated (past tense)) /only/ fixes that one example line of code, not the actual problem, even though the problem itself /and the whole solution/ (a single line and some edits further on) is posted right there.

Yes, the certification report is sixteen pages of stuff you can skip, but does it really cost you too much time to read that one page for the actual solution and the thing you have to do?