KISS Principle: Cleaning Up Code Left by Previous Programmer

  • Thread starter Thread starter Borg
  • Start date Start date
  • Tags Tags
    Stupid
Click For Summary

Discussion Overview

The discussion revolves around the challenges faced by programmers when dealing with overly complex code left by previous developers, particularly in relation to the KISS (Keep It Simple, Stupid) principle. Participants share personal experiences, anecdotes, and observations about code complexity, productivity metrics, and the implications of poor coding practices in software development.

Discussion Character

  • Exploratory
  • Debate/contested
  • Technical explanation
  • Conceptual clarification

Main Points Raised

  • One participant describes removing unnecessary class files and simplifying code that was overly complex, questioning the rationale behind such design choices.
  • Another participant suggests that the previous programmer may have been influenced by a workplace culture that valued lines of code (LOC) as a productivity metric.
  • Some participants share their own experiences with negative LOC, indicating that they often reduce code complexity significantly.
  • Anecdotes are shared about the Y2K remediation efforts, highlighting the challenges of legacy code and the lack of motivation to clean it up until a crisis occurred.
  • Concerns are raised about the potential for new programmers to overcomplicate designs by creating unnecessary interfaces, which can hinder code readability and debugging.
  • Participants discuss the impact of company policies on software installations and how this can complicate development processes.
  • There is a sentiment expressed that some programmers may intentionally create convoluted code to maintain job security or enhance their resumes.
  • One participant notes the importance of communication within teams regarding code changes and the positive outcomes of simplifying code.

Areas of Agreement / Disagreement

Participants express a range of views on the causes and implications of complex coding practices, with no clear consensus on the best approaches to take or the motivations behind such practices. The discussion remains unresolved regarding the effectiveness of various coding philosophies and workplace metrics.

Contextual Notes

Participants mention various factors influencing coding practices, including workplace culture, management expectations, and personal experiences with legacy code. There are references to specific metrics and anecdotal evidence without definitive conclusions on their impact.

Who May Find This Useful

Software developers, project managers, and those interested in coding practices and team dynamics in software development may find this discussion relevant.

  • #31
I agree with the naming conventions. Often on projects, when I am trying to track down how something works, I will invariably run into multiple, unrelated classes with identically named methods like processData(). Performing a search on stuff like that is impossible when there are a lot of them. IDEs are pretty good at figuring out usages except for cases like the obfuscated code that I'm having to deal with. It has been painful. It shouldn't take lead develpers a full day to figure out how to change the displayed text on a web page but it often does. If the guy had at least not used so many common names that were constantly changing as they traversed the code...
 
  • Like
Likes   Reactions: QuantumQuest
Technology news on Phys.org
  • #32
The best exposition of variable names I've seen is Steve McConnell's "Code Complete." Chapter 9 of this book has suggestions for how a programmer should name the variables being used, together with examples of useful names and awful names.

Here's a Coding Horror example:
C:
X = X - XX;
XXX = Aretha + SalesTax( Aretha);
X = X + LateFee( X1, X) + XXX;
X = X + Interest( X1, X );
I've seen a lot of Fortran code with names just as bad as those in this example.

As McConnell says, "the most important consideration in naming a variable is that the name fully and accurately describe the entity the variable represents."

He talks about the Hungarian convention for variable names, and cites advantages as well as disadvantages of this naming scheme.
 
  • Like
Likes   Reactions: QuantumQuest
  • #33
The Naming section in the link in my signature has some great examples of poor naming. Number 18 has always been my favorite:
18. Bedazzling Names
Choose variable names with irrelevant emotional connotation, e. g.:
marypoppins = ( superman + starship ) / god;
This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they’re trying to think about.
 
  • Like
Likes   Reactions: QuantumQuest
  • #34
A technique that I often use with Visual Studio is to define my variables in nested structures or classes. This helps me a lot with my poor memory because the IDE will show me a drop down of all the members of the struct or class as I type out the variable name. An example would be: TestData.Mux1.Voltage(x) or TestData.Mux2.Amps(x) When I type TestData. the IDE will show me a dropdown of all instruments connected, and when I continue by typing TestData.Mux2. the IDE will show me a dropdown of all data arrays for that instrument. The question for me recently has been whether to use structs or classes. From what I've read, struct variables are stored on the stack and class variables are stored on the heap. So the struct variables should be faster but the class variables should be more memory efficient.
 
  • #35
and what is Mux1 or Mux2? multipliers? However I belong to the people who use vi [at least in office- at home I have IDEs], and this feature is not available to me...
I plan to move soon.
 
  • #36
ChrisVer said:
and what is Mux1 or Mux2? multipliers? However I belong to the people who use vi [at least in office- at home I have IDEs], and this feature is not available to me...
I plan to move soon.
Yes, it's short for multiplexer.
 
  • #37
I still am amazed at the stuff that I continue to find. In one process that processes XML for storage into the database, I found the following:
XML sections are processed via a file that describes the class to use for a particular field.
One set of entries changed had an additonal config setting that changed the name of the field slightly.
The class file (ActualImplClass below) then has enums that define those particular name changes and the code looks for those instead of the original name like everything else.
Additionally, the ActualImplClass of course implements an interface with ActualImplClass being the only implementation of that interface in the system.
The ActualImplClass is also never called directly. Instead, there is another class which provides it as a variable.
That variable is also obfuscated by instantiating it from a string variable that never changes and then instantiates it through a class loader - something like this:
Java:
public class FinalClass extends ImplementationClass{
    private String implClassName;

    public FinalClass(){
        implClassName = "com. biz.ActualImplClass";
        // ActualImplClass implements SomeInterface and is the only implementation in the entire project (very typical)
    }

    public SomeInterface instantiateInterface(){
        Class<SomeInterface> interface = (Class<SomeInterface>)getClass().getClassLoader().loadClass(implClassName);
        return interface;
    }
}
implClassName also has a setter and getter so that you could change it on the fly but nothing ever called it.
What all of this basically does is change a name unnecessarily and bury that fact in a bunch of obfuscated code that was completely unnecessary.
 
Last edited:
  • #38
TurtleMeister said:
The question for me recently has been whether to use structs or classes. From what I've read, struct variables are stored on the stack and class variables are stored on the heap. So the struct variables should be faster but the class variables should be more memory efficient.
Sorry for being a bit late to the party, but I'm pretty sure that, in C++, the only difference between struct and class is that the members of struct are public by default, and members of class are private by default. So, for example,
C++:
#if MARYPOPPINS
struct Superman {
#else
class Superman { public:
#endif
should do the same thing, whether MARYPOPPINS is true or false.
 
  • #39
TurtleMeister said:
From what I've read, struct variables are stored on the stack and class variables are stored on the heap.
No, that's not true. A variable of either type that is declared inside a function is allocated space on the stack. Variables that are declared using the new operator are allocated on the heap. However, I suppose it would be possible to use the "placement new" operator to return a pointer to previously allocated memory, possibly on the stack. You would have to go to extra effort to do this.
TurtleMeister said:
So the struct variables should be faster but the class variables should be more memory efficient.
As far as I know, neither of these is true. The stack and the heap are just memory -- they just happen to be in different sections of it. Access to either part would take the same amount of time, and a variable stored on the heap uses just as much space as one stored on the stack.
 
  • #40
Thanks, I had read conflicting information on programming forums and sites about the stack vs heap in regards to speed. When googling "which is faster heap or stack", the overwhelming consensus seemed to be that the stack is faster. But it is the internet, and sometimes sites will just copy the same wrong information from each other. Some seem to think that the difference is not really worth considering. But sometimes I like to play around with n-body simulations where I need to access a lot of variables with as much speed as possible. So I'm thinking it might make a difference in that application. But I'm getting off topic so I'll leave it at that. Thanks for the replies.
 
  • Like
Likes   Reactions: Borg
  • #41
phinds said:
I was often an unpopular manager because of my insistence on extensive documentation except in those cases where the programmers knew that THEY were going to have to maintain their code. Only novice programmers think that in a few years they will have a clear understanding of code just because they were the ones who wrote it.
Hear, hear! When I was in charge of program development,I always insisted on having a clear program description before I allowed anybody to start programming. When that was done, the description was imported into the program as a sequence of comments and the actual code could be stuck in between the appropriate comments.
 

Similar threads

  • · Replies 16 ·
Replies
16
Views
2K
  • · Replies 3 ·
Replies
3
Views
1K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 1 ·
Replies
1
Views
5K
  • · Replies 15 ·
Replies
15
Views
3K
Replies
5
Views
8K
  • · Replies 4 ·
Replies
4
Views
7K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 11 ·
Replies
11
Views
3K