Dumb refactoring

Refactoring is supposed to make code better, nicer, faster,
more readable? How about Refactoring for certification tests
or, shortly, Dumb Refactoring? I think that author of such
refactoring plugin could charge a little more than usual,
and he will get payed, because when a company is charged
with tens of thousands dollars to certify the product, it
would rather pay for such "uglifier" to make the process
quick and less painful.

I know this sound crazy, but this is what we have to do with
our code to make it pass through ceritication process. Say,
we have a method:

/**

  • Obtain a property by name.


  • @param propName property name


  • @return property value, or null if properties has not

been loaded

*/

public String getProperty(String propName) {

return theProperties == null ? null :
theProperties.getProperty(propName);

}



Coding standard does not allow ternary operation, so we
change method into:



public String getProperty(String propName) {

if (theProperties == null)

return null;

else

return theProperties.getProperty(propName);

}



Coding standard requires that statements in condition and
loop operators should be surrounded with braces. Also,
multiple return statements per method are not allowed, so:



public String getProperty(String propName) {

String property = null;

if (theProperties == null) {

property = null;

} else {

property = theProperties.getProperty(propName);

}

return property;

}



Every line in the code should be commented, does not matter
how stupid the comments are, so they can be easily
autogenerated like this:



public String getProperty(String propName) {

// Declaring string property

String property = null;

// Checking if theProperties is null

if (theProperties == null) {

// Set property to null

property = null;

} else {

// Set property to the value from getProperty() method

property = theProperties.getProperty(propName);

}

// Return property value

return property;

}



The same standard requires that javadoc comment for a method
contained all non-local variables used in the method, the
call sequence (whatever it is) and the files (for
simplicity, objects of type File) used in the method. The
"proper" method would look like this:



/**

  • Obtain a property by name.


  • @param propName property name


  • @return property value, or null if properties has not

been loaded

  • <pre>


  • Sequence:


  • theProperties.getProperty()


  • Files:


  • none


  • Global variables:


  • Properties theProperty


  • </pre>


*/

public String getProperty(String propName) {

// Declaring string property

String property = null;

// Checking if theProperties is null

if (theProperties == null) {

// Set property to null

property = null;

} else {

// Set property to the value from getProperty() method

property = theProperties.getProperty(propName);

}

// Return property value

return property;

}



There are a lot of other stupid requirements, like instead
writing conditions in normal way:



if (somethingHappened()) {

...

}



it should look like:



if (somethingHappened() == true) {

...

}



Btw, factoring out this expression into the following:



somethingHappened = somethingHappened() == true;

if (somethingHappened) {

...

}



does not cut it ;) or :(



Or naming variables with one letter or having variables
differ in one letter only... A lot of ugly stuff, which we
have to cope with, while development is not moving.



Any takers? ;))



Michael.

8 comments

Wow, that has to be painful :( (And the worst 'standards' I have
seen in a long time).

Good luck dealing with this kind of stuff.

Vince.


0

Michael Jouravlev wrote:

Any takers? ;))


I could probably build a tool to do this stuff automatically quite
easily. I would have to charge a enormous amount of money though, this
is clearly the devils work and I'd be selling my soul;-)

Bas

0

Well, that thing about consolidating return points is actually really, really difficult to automate in Java, what with try-catch-finally blocks and the like. I looked into the problem for about five minutes, and then decided to have a beer instead. Other than that, everything looks doable, except for putting in the comments. For that, you'll need to use this product from Cenqua http://www.cenqua.com/commentator/ .

I'm with Bas on the pricing, by the way. Coding up something like that's not worth what I would have to pay to clean the stench off my hard-drive.

--Dave Griffith

0


"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:4879833.1134134072767.JavaMail.javamailuser@localhost...

Well, that thing about consolidating return points is

actually really, really difficult to automate in Java, what
with try-catch-finally blocks and the like. I looked into
the problem for about five minutes, and then decided to have
a beer instead. Other than that, everything looks doable,
except for putting in the comments. For that, you'll need
to use this product from Cenqua
http://www.cenqua.com/commentator/ .

Thanks, I will take a look. Actually, I already wrote a
simple source code parser myself. I guess we should have
hired a college undergrad for that, I've heard that they
have term tasks like that (writing a lexic parser) ;)
>

I'm with Bas on the pricing, by the way. Coding up

something like that's not worth what I would have to pay to
clean the stench off my hard-drive.

Agreed. This $hit should cost mucho dinero. No fun indeed.

0

You might want to forward this to Rody Green, so he can revise his 'how to write unmaintanable code' essay :-/

http://mindprod.com/jgloss/unmain.html

0

For that, you'll need to use this product from Cenqua
http://www.cenqua.com/commentator/


They should release this product. I'd definitely buy if if it was cheap just for the look on my colleagues faces!! ;)

0

The commentator is definitely awesome :) Too bad I missed the purchasing
window...

Vince.


0

Please sign in to leave a comment.