KISS Principle: Cleaning Up Code Left by Previous Programmer

[TurtleMeister]

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.

 

[Borg]

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:

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.

 

[SlowThinker]

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,

#if MARYPOPPINS
struct Superman {
#else
class Superman { public:
#endif

should do the same thing, whether MARYPOPPINS is true or false.

 

[Mark44]

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.

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.

 

[TurtleMeister]

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.

 

[Svein]

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.