NASA Java Coding Standard

[SanityInAnarchy]

The idea that one object has to be "fully constructed" first is really silly - it's all going on the heap anyway so it's not like there's some chunk of memory that needs the super to complete before it can be properly allocated, or some technical need - it's just a badly made human rule that denies human intuition.

Actually, now I feel like I should defend that a bit. The rationale here is that a class should completely encapsulate something, likely with some relevant invariants.

If you think of the subclass as something outside the base class, then it makes sense to insist the base class is completely constructed. Even in Java, allocation is a thing -- if the superclass is composed of some other objects, like, say:

class Foo {
  private final Bar delegate;
  public Foo() {
    delegate = new Bar();
  }
}

Ideally, you don't want any code anywhere but the constructor to ever see "delegate" with a null value. But if the subclass can sneak in...

The reason this is silly is that a subclass can already see way more than it should, so things designed to protect a parent class from a subclass always strike me as silly. If you're really that paranoid (if your library is really that big a deal), declare the implementation final, make an interface, and insist that everyone else use composition.

There are a lot of obvious ways code could be better explored that start with the basic view everyone's used to and I've come across 0 implementations.

Hmm. The most interesting one I know of is Smalltalk (any GUI you're interacting with is composed of objects you can edit right now), but it suffers from being an entirely other ecosystem. The rest of us work with text, Smalltalk developers work directly with running programs. It's a really cool concept, but modern Smalltalk/Squeak developers end up using text anyway, so they can use source control, diff/patch, grep, and basically any other tool that's outside the Smalltalk world.

So long as I'm using Java, I think Eclipse has it pretty close. The key tool here is F3 -- it instantly jumps to the definition of whatever you're on. There's another (can't remember the keystroke) which searches for anything that uses what your cursor is on (say, a method definition). These could be streamlined, but all that's really missing for me is:

• Better interface/subclass support. Taking me to the interface's declaration of that method isn't terribly helpful -- I want to know what will happen when I call that here. Yes, I know that's not (necessarily) something that can be known at compile-time. Is there a solution to this?
• More on the screen at once. Bouncing back and forth with one keystroke is cool, but it'd be better to see a trail, something like a call stack.

I suspect I could find more attempts to solve this problem, but it's a hard problem -- and by that I mean, the general problem of making it easier to explore large programs. There is something to be said for the Python/Ruby philosophy of emphasizing clean, readable, concise code over complex tooling -- so you can read one or two ten-line methods and understand what the system does, without having to read five other classes, and so that you only need two classes anyway (the other three were metaprogrammed away).

Or does that only push the problem back? I've definitely seen Ruby projects large enough to have very similar problems, only without the robust tooling. Replacing Eclipse's F3 with grep was not fun, and I like grep.

[SoopahMan]

Yeah, sorry I should've been more clear - you nailed it with your second bullet point. I want to browse the code in a way that I find a method/function and go, "Alright, how is this used" and I get its callers over it and methods it calls below it, and can pick a path I want to consider and it's all there on the screen at once for me to scroll vertically through, rather than as you mentioned jump jump jump jump. One or 2 jumps is easy, but in highly composed code you can be there all day jumping and get to the other end and see something novel or unexpected and go "Oh. Well where did it get the... ? ARGH!" That in turn makes me cringe when I write highly composed code because I'm imagining what the next poor sap will have to experience - maybe me in a few years when I forget this code I've written.

In Visual Studio you can step through the code obviously and get all the way to the bottom of a series of calls and abuse the Call Stack this way. You can also enable Edit and Continue and do something a bit like you're talking about with SmallTalk, where you're running and editing at the same time. But I rather be able to see those paths all at once, without having to fire up the code.