I don't know if I'd say its the biggest problem but over engineering to the point of masturbation does seem to be quite prevalent in java today.

As much as I love to pile on adjectiveLibrary.ClassNoun.PronounFunction.VerbIns ult.JavaIsStupid(), I think the over-engineering of code is not limited to just Java. A significant amount of the Daily WTFs are pointless object-oriented garbage in multiple languages. Just abstract it away, away, away!

I'm using Eclipse, but it's not an issue of being annoyed because I have to make 4-5 extra keystrokes.

I don't accept this premise:

except for the fact that you can obviously make more extreme mistakes on the not being granular enough side. But being far too granular completely hurts readability of the code and can make minor changes kind of painful (because you have to push/pull something up/down through all of these functions/classes).

"biggest problem" is definitely an exaggeration on my part but the bolded certainly sums up well the point I was trying to make.

I'd have to say that you've never worked with code that routinely has 600 line methods and 5000 line classes. Basically, you have to refactor the code just to understand it. It's absolutely awful. What you are describing seems like a minor annoyance. You'd have to give me a specific example of what push/pulling something though, not sure what you mean so maybe I am missing your point.

Yeah, I also do not accept that premise straight up. Certainly I try to make the majority of my code reusable, but what is the meaningful difference between having far too many lines in a function and far too many functions in a program? Both are horrible for maintenance.

A 600 line method sounds bad, but so does 250 methods of 3 lines each. (I don't believe that a reasonably written procedural block of code could be abstracted to X*Y = Z lines; if so, then the problem is not the fact that it's procedural - it's the fact that the original developer was an idiot.)

600 line methods and 5000 line classes are obviously examples of the extreme mistakes that I admitted are worse than any code that is broken up/abstracted too much.

But I don't accept that a single 50 line function is automatically worse than 15 2-5 line functions (spread over multiple classes) implementing the same logic.

Anyway, didn't mean to start a silly debate. Just ranting about Java.

yeah this is fair, though i would ask why, when a 50 line method is broken down, its submethods disperse to different classes. That indicates a class architecture problem to me. i would say that 15 2-5 line method in a single class are very likely to be more readable and maintable code than a single 50 line method.

Here's my problem - I can fit about 50 lines of code vertically on my screen. If I have one function with 50 lines I can sit back and stare at it for 15 seconds and figure out what's happening. If I take those 50 lines and spread them out over 10 functions I now have something like 80 lines of code and I can't see it all at the same time.

Having a method called: "setVariableX(Y)" is no more clear than "x = y;".

If you're moving 2 lines of code into a function I'm skeptical that the name of that function is going to be significantly more clear to me than just seeing the lines of code (meaning that I'm not getting enough additional benefit to offset the fact that I have to navigate through code). I don't think you can do many meaningful things in that few lines of code.

The problem is even worse if I'm now jumping between files or dealing with a polymorphic object and it's not even clear what right function to look at is.

Edit: Realized I didn't completely answer your question. The methods are often dispersed to different classes because some people totally over engineer and really believe strongly in a very narrow definition of each class must do a single thing. I agree, it's just a class architecture problem - but its one that I see a lot in Java because of people semi-blindly applying design principles.

This is true.

This is not true. You don't look at 50 lines and take them all in, even if it feels that way to you sometimes. If you are refactoring properly, and naming your methods clearly, the code you are looking at becomes both shorter and clearer. You won't need to look at the offscreen code because your new method name tells you what it does. You would only have to go to the new method if your were interested in its implementation details, rather than what the method you are looking at is doing. This is the way it should be.

I think the argument is not fruitful without a specific example though. I would be pretty shocked if I couldn't refactor a 50 line method for you in a way that you'd agree was much better.

Also in .net there are #regions which I don't think will ever be in java

So I can take my 50 line function and split it into 3 sections like

Read data
Process data
Write data

It might seem like an opportunity to have 3 functions here but I'd be passing either a ton of parameters or need to make a new class

1. While you obviously can't look at them all at the same time - you have to agree that it's much easier/faster to just move your eyes than it is to navigate through the code.

2. I'm not saying 50 lines of code is optimal. That was just to point out why I don't agree with your claim that too granular is a much less serious error than too granular.

3. I understand proper refactoring and that it should lead to methods that avoid having to look at the implementation for that code. But my whole rant is around all the people that think proper refactoring is just making small functions. The people that see a 20 line function and break it up into 4 functions of 5 lines each - without actually thinking about the logical coherence of those 4 functions.

3b. I'm skeptical of the claim that you can usually ignore the implementation of the refactored out method and just look at its name for clarity. I don't trust the average developer enough to not look at the implementation when I'm learning what a class does or thinking about modifying it. It's always seemed like a claim that only applies to very certain circumstances.

If this is the case, what's the point of doing any abstraction?

While I agree with your other points from this post, 3b is so so wrong. If other developers have to look at implementation details of methods you've written, you have written them incorrectly. It completely misses the point of encapsulation and information hiding.

EDIT: Also i disagree with 1. It much easier for me to hit F3 and look at just the code I am interested in than to mentally block out the surrounding code.

This doesn't make any sense and sounds wrong to me, but I'd have to see a specific example to know for sure.

random, anyone know of a website that would run regex on sql statements and see if they are valid / find errors?

currently dealing with software that has alot of very long and complicated sql statements running with no verification and giving errors on alot of the statements....

Quick google found Mimer SQL Validator. They say it only checks against that standards, so if you use any DB specific things, it will not work.

interesting stackoverflow result from that: http://stackoverflow.com/questions/1...mon-sql-syntax

For anyone that hasn't seen it. The best answer to a question asking to use regular expressions on a non-regular language.

heh i did google for a bit, didnt find anything relevant esp in the terms of simplifying the sql... though my brain may just be fried from working last few days using a completely undocumented database with status codes that I have no idea the meaning of placing into tables under certain conditions etc...

I guess this boils down to our general faith in other developers. I'm still not entirely sure you get that I'm not advocating a specific optimal style here and am instead ranting about the reality that I find.

Ok, good for you. Not to mention F3 is great to get to a method, and then sometimes you don't always have a quick key to get back to where you were before.

i do get it, and sorry to get into argument when you were just venting, but i do think it's an important point and it has nothing to do with faith in developers. you NEVER need to understand the implementation of code that you are just using, that is the whole point of interfaces and OO programming. the only exception would be if that implementation code had a bug or needed to be optimized.



how about the eclipse back button?

Except, I'm specifically talking about code that I want to update/modify. I just don't buy this reality of looking at a function you want to change/extend and NEVER looking at what's actually happening in the helper functions being called. It seems a recipe for disaster.

It's only a problem if the helper functions have problems in them. And anyway if you do the way I suggest, even if you are interested in modifying the implementation code of helper functions for whatever reason, you will find the code faster. Like I said though, this is silly without a concrete example. Why don't you paste in some function that does multiple things, that you think is better as one big function. I will try to convince that it's better broken down with a specific refactoring.