KISS Principle: Cleaning Up Code Left by Previous Programmer

  • Thread starter Thread starter Borg
  • Start date Start date
  • Tags Tags
    Stupid
Click For Summary
Cleaning up code left by a previous programmer revealed a lack of adherence to the KISS principle, resulting in over 75 unnecessary class files and convoluted structures that complicated maintenance. The discussion highlighted the issue of programmers creating overly complex solutions, possibly due to metrics like lines of code (LOC) being misused as productivity measures. Participants shared experiences of dealing with similar codebases, emphasizing the importance of simplicity and proper documentation to avoid future headaches. The conversation also touched on the challenges of adapting code for different technologies and the necessity of maintaining clarity in programming practices. Ultimately, the need for a balance between abstraction and straightforwardness in coding was underscored.
  • #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 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 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 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 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
1K
  • · Replies 1 ·
Replies
1
Views
4K
  • · Replies 15 ·
Replies
15
Views
3K
Replies
5
Views
7K
  • · Replies 4 ·
Replies
4
Views
7K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 11 ·
Replies
11
Views
3K