Refactoring: How do I even start?
11–20 of 41 posts
Re: Refactoring: How do I even start?
#12Earlier quoted context omitted.
> The author doesn't even notice that the second argument of && is redundant and keeps it in the "refactored" version as well.. That's false. A list object may be initialized but be empty (making it's length zero). Or it may not be initialized (making it null). Both conditions may happen independently of one another. He checks for the null first so that checking the length does not throw a NPE. > The if-statement is…
He then proceeds to iterate over the list using zero based indexing. The loop would not execute once if the list had length zero, making this check just plain wrong. I know an even lower level language (C++, C) that doesn't have the problem of things which make no sense to be NULL (list elements). The problem is that Java did away completely with value types and made everything pointer only. That has been recognized…
You must null check a lot of things in C, especially since there is no graceful error handling (try/catch blocks)... C certainly allows things to be null (or garbage) values.
> The problem is that Java did away completely with value types and made everything pointer only.
I'm not sure what you are saying here -- the very notion of pointers do not exist in Java. This decision was made while creating the language, and avoids an entire class of programming errors. Java is strictly pass by value.
> the third is the missing for-each construct.
I completely agree with you here. Java does have a for-each construct, and it's recommended to use whenever possible. It avoids an entire class of programming errors.
Re: Refactoring: How do I even start?
#13Earlier quoted context omitted.
> The author doesn't even notice that the second argument of && is redundant and keeps it in the "refactored" version as well.. That's false. A list object may be initialized but be empty (making it's length zero). Or it may not be initialized (making it null). Both conditions may happen independently of one another. He checks for the null first so that checking the length does not throw a NPE. > The if-statement is…
He then proceeds to iterate over the list using zero based indexing. The loop would not execute once if the list had length zero, making this check just plain wrong. I know an even lower level language (C++, C) that doesn't have the problem of things which make no sense to be NULL (list elements). The problem is that Java did away completely with value types and made everything pointer only. That has been recognized…
Your language hate and insistence that the programmer himself is one of the "problems" is why people don't do code reviews, and why people get overly defensive if you offer constructive criticism of code. Your criticism is not constructive.
If you are in a position of power or mentorship I suggest you take a moment to think how your words and actions influence those around you, particularly those less experienced who may look up to you.
Re: Refactoring: How do I even start?
#14Earlier quoted context omitted.
> The author doesn't even notice that the second argument of && is redundant and keeps it in the "refactored" version as well.. That's false. A list object may be initialized but be empty (making it's length zero). Or it may not be initialized (making it null). Both conditions may happen independently of one another. He checks for the null first so that checking the length does not throw a NPE. > The if-statement is…
He then proceeds to iterate over the list using zero based indexing. The loop would not execute once if the list had length zero, making this check just plain wrong. I know an even lower level language (C++, C) that doesn't have the problem of things which make no sense to be NULL (list elements). The problem is that Java did away completely with value types and made everything pointer only. That has been recognized…
Re: Refactoring: How do I even start?
#15Earlier quoted context omitted.
He then proceeds to iterate over the list using zero based indexing. The loop would not execute once if the list had length zero, making this check just plain wrong. I know an even lower level language (C++, C) that doesn't have the problem of things which make no sense to be NULL (list elements). The problem is that Java did away completely with value types and made everything pointer only. That has been recognized…
> I know an even lower level language (C++, C) that doesn't have the problem of things which make no sense to be NULL (list elements) You must null check a lot of things in C, especially since there is no graceful error handling (try/catch blocks)... C certainly allows things to be null (or garbage) values. > The problem is that Java did away completely with value types and made everything pointer only. I'm not sure…
You are correct that adding C as an example language was wrong. C++ on the other hand still stands.
> I'm not sure what you are saying here -- the very notion of pointers do not exist in Java
Java references are just C pointers without pointer arithmetic.
Re: Refactoring: How do I even start?
#16"Refactoring" does not mean "previous programmer was an idiot". Often, the understanding of the problem and the way the code is used change over time. Refactoring is a way of bringing the out-of-control weeds back into healthy symbiosis with the larger garden of code.
I stopped telling clients a long time ago that I'm "refactoring" and instead I just add some extra time to all tasks to account for refactoring on legacy code.
Re: Refactoring: How do I even start?
#17> is the name of the blog; the title of submitted post is "Refactoring: How do I even start?". Could mods change this please?
Re: Refactoring: How do I even start?
#18Earlier quoted context omitted.
He then proceeds to iterate over the list using zero based indexing. The loop would not execute once if the list had length zero, making this check just plain wrong. I know an even lower level language (C++, C) that doesn't have the problem of things which make no sense to be NULL (list elements). The problem is that Java did away completely with value types and made everything pointer only. That has been recognized…
My word, something can be redundant (not conceding that point) and not "just plain wrong." Your language hate and insistence that the programmer himself is one of the "problems" is why people don't do code reviews, and why people get overly defensive if you offer constructive criticism of code. Your criticism is not constructive. If you are in a position of power or mentorship I suggest you take a moment to think how…
I think we can agree to disagree. I'm strictly against redundancy if it doesn't serve a well-defined purpose.
> Your language hate and insistence that the programmer himself is one of the "problems" is why people don't do code reviews, and why people get overly defensive if you offer constructive criticism of code. Your criticism is not constructive.
I would phrase my criticism entirely different if the recipient was someone who asked for my commentary and not someone who felt confident enough to write a blogpost on how to start refactoring code.
Re: Refactoring: How do I even start?
#19Re: Refactoring: How do I even start?
#20Earlier quoted context omitted.
My word, something can be redundant (not conceding that point) and not "just plain wrong." Your language hate and insistence that the programmer himself is one of the "problems" is why people don't do code reviews, and why people get overly defensive if you offer constructive criticism of code. Your criticism is not constructive. If you are in a position of power or mentorship I suggest you take a moment to think how…
> My word, something can be redundant (not conceding that point) and not "just plain wrong." I think we can agree to disagree. I'm strictly against redundancy if it doesn't serve a well-defined purpose. > Your language hate and insistence that the programmer himself is one of the "problems" is why people don't do code reviews, and why people get overly defensive if you offer constructive criticism of code. Your criti…
Well, a good optimizing compiler might factor redundant checks out. The JVM has one of the best optimizing compilers around... Sometimes source code clarity is better than "absolute correctness", especially when we're discussing something trivial.