What's NetBeans written in?

[Twisted]

If they both used a COMMON beautifier before checkin, CVS would report
only REAL changes to code, not ones artifacts of differing styles of
beautification.

It sounds like CVS isn't very smart, and in particular doesn't know
semantically-significant whitespace changes from semantically-
insignificant ones. Perhaps this means they should choose a different
version control product.

SVN comes highly recommended with such features as:

"The diff engine internal to Subversion can now ignore whitespace and
eol-style when computing the diff."

(since version 1.4; http://subversion.tigris.org/svn_1.4_releasenotes.html)

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Let's say programmer A checks out the code and does some extensive
work with in IntelliJ. Almost certainly he will hit Ctrl-Alt-R
several times to make the code comprehensible. It will beautify to
IntelliJ specs.

Then he checks it in. Programmer B checks it out in Eclipse and does
a simple modification. Hits the beautify button, which will beautify
to Eclipse standards -- potentially changing every line in the
program, changed or not. He then checks it in.

Then programmer A checks it out again. And tries to figure out what
Programmer B changed. CVS tells him every line in the program had a
delta.

If they both used a COMMON beautifier before checkin, CVS would report
only REAL changes to code, not ones artifacts of differing styles of
beautification.

Now SUN has actually published a guide for Java style.

Eclipse has this style as default.

I would assume IntelliJ can also do that.

If not then developers using InteliJ should not attempt to
beautify the code.

Arne

 

[blmblm]

The smartest boss I ever had was also so meticulous he drove team
members mad. Further he could not appreciate that everyone was not as
brilliant as he was. He expected everyone to follow extremely
intricate code as effortlessly as he did.

Several times in my life I have had the exquisite pleasure to lead a
team of highly competent people who did not fight with me, but who
were not shy about pointing out my errors. It is the most incredible
feeling to see finished code pouring out at a clip an order of
magnitude faster than I could possibly do it myself, all done the way
I would have had I the time and patience.

Being the boss is such a pleasure, I can see why incompetent people
love to try anyway.

But would an incompetent person get pleasure from something useful
taking place faster than he/she could do it myself? and it's just
cynicism to suppose that the appeal of managing is the opportunity
to push people around?

(Good story, though.)

 

[Twisted]

Now SUN has actually published a guide for Java style.

Linkie?

 

[Twisted]

But would an incompetent person get pleasure from something useful
taking place faster than he/she could do it myself? and it's just
cynicism to suppose that the appeal of managing is the opportunity
to push people around?

It's different reasons for different managers. Good managers are
probably like Roedy described. Managers whose real love is pushing
people around are generally going to be bad managers.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Linkie?

http://java.sun.com/docs/codeconv/

Arne

 

[Twisted]

http://java.sun.com/docs/codeconv/

Thanks.

Huh. To judge by the "code example", it's nearly identical to how I've
always styled my code for decades, save two things:

I put a space between method name and ( in method headers (but not
method calls).

When coding C++, I usually write short little methods all on one line,
e.g. in an iterator of some sort I might write:

inline my_iterator operator++ () { inner = inner->next; return
this; }

which is of course irrelevant to Java (and I rarely touch C++ these
days anyway now that JVMs can run Java as fast as native code).

(Obviously the above iterator would also have an operator bool to test
for inner becoming null, and would blow up horribly if not tested for
this. Equally obviously any Java equivalent I wrote would have
hasNext() checking for the equivalent of inner->next == null and a
next() throwing a suitable exception if already at the last element.)

 

[Lew]

It sounds like CVS isn't very smart, and in particular doesn't know
semantically-significant whitespace changes from semantically-
insignificant ones. Perhaps this means they should choose a different
version control product.

SVN comes highly recommended with such features as:

"The diff engine internal to Subversion can now ignore whitespace and
eol-style when computing the diff."

(since version 1.4; http://subversion.tigris.org/svn_1.4_releasenotes.html)

The cvs "diff" command, like the UNIX one it's based on, can ignore
whitespace, too, and has had that ability for as long as I've used CVS (over
seven years, now).

 

[Lew]

http://java.sun.com/docs/codeconv/

"Now" being since 1999.

 

[blmblm]

It's different reasons for different managers. Good managers are
probably like Roedy described. Managers whose real love is pushing
people around are generally going to be bad managers.

Yeah. I think I had should have some more caffeine before sending
that post out into cyberspace -- "could do it myself" when I meant
to write "could do it himself/herself" [1], not to mention that
I didn't really get across the point I was trying to make, which
had to do with the appeal of management to incompetent people.

I think you're probably right [2], though -- "good manager"
probably implies "motivated by what Roedy describes", while
"motivated by a love of power" probably implies "bad manager".
I doubt that the converse of either statement is invariably
true, though.

[1] Lew may want singular "they" here -- but neither "themselves"
nor "themself" sounds quite right. Recast the sentence in the
plural, I guess.

[2] We agree on something?! Sort of a .

 

[Lew]

Yeah. I think I had should have some more caffeine before sending
that post out into cyberspace -- "could do it myself" when I meant
to write "could do it himself/herself" [1], not to mention that ....
[1] Lew may want singular "they" here -- but neither "themselves"
nor "themself" sounds quite right. Recast the sentence in the
plural, I guess.

I'd use "themselves". Managers have split personalities anyway. One for
their superiors, and one for their minions.

 

[Guest]

"Now" being since 1999.

"Now" was not intended to be in a "at the present moment" sense.

Arne

 

[Mike Schilling]

It sounds like CVS isn't very smart, and in particular doesn't know
semantically-significant whitespace changes from semantically-
insignificant ones. Perhaps this means they should choose a different
version control product.

SVN comes highly recommended with such features as:

"The diff engine internal to Subversion can now ignore whitespace and
eol-style when computing the diff."

That's common to many SCMs. It would have to be much cleverer to ignore
changes in, say, brace style. And should it ignore the difference between

if (i > 5)

and

if (i>5)

Perhaps for Java (though probably not). Definitely not for a file intended
to be read by humans.

 

[Mike Schilling]

Now SUN has actually published a guide for Java style.

It's hardly exhaustive. Take imports as an example.

Are wildcard imports allowed? If so, when should they be used?
How should imports be ordered?
Are blank lines allowed to separate groups of related imports?

(In case anyone cares, my answers are "no", "alphabetically", and "maybe"
respectively.)

Beautifiers that make diferent decisions here will create spurious diffs
that no SCM system will be able to eliminate. And one of my most common
beautification commands is IntelliJ's "Optimize imports" which (with my
settings) applies my rules.

 

[Twisted]

That's common to many SCMs. It would have to be much cleverer to ignore
changes in, say, brace style. And should it ignore the difference between

if (i > 5)

and

if (i>5)

Perhaps for Java (though probably not). Definitely not for a file intended
to be read by humans.

Eh. Both of these:

if (i > 5) {
return foo;
}

and

if (i>5)
{ return foo; }

become

if(i>5){return foo;}

when semantically-insignificant whitespace is eliminated and
semantically-significant whitespace (which would run keywords/
identifiers together or cause a // comment to run further if omitted)
is reduced to single spaces (linefeeds in the case of terminating a //
comment). (In this case the single space between "return" and "foo"
remains.)

You'll still get spurious deltas from changing

if (i > 5) return foo;

to any brace-using form of course. But simply reindenting everything
with your preferred tab width or whatever shouldn't cause deltas with
these options.

 

[Roedy Green]

The smartest boss I ever had was also so meticulous he drove team
members mad. Further he could not appreciate that everyone was not as
brilliant as he was. He expected everyone to follow extremely
intricate code as effortlessly as he did.

The employee from hell was on a team I was not leading. We both
figured it was time for some refactoring. The boss said no, we could
not take the time just now. I accepted the boss's decision, given it
was his money, he did understand our concerns and he had access to
other considerations that I did not.

However, the other guy went ballistic and wanted to stage a sort of
coup. I refused to go along. He felt betrayed. He became furious with
me for not supporting him and started phoning me and haranguing me on
my every shortcoming. I eventually could not handle this and had to
resign.

It is quite a different skillset to play on a team and to develop by
yourself and to be the boss.

 

[Roedy Green]

It's different reasons for different managers. Good managers are
probably like Roedy described. Managers whose real love is pushing
people around are generally going to be bad managers.

When I have had things really click, there a virtuous circle. I am so
happy with the people working for me helping me get so much done, that
they work even harder to amaze me. I just beam with pleasure at them.
Everybody takes joy in the productivity of the entire team and it acts
like an oil to rapidly decide how to do a compromise.

Then you start getting comments from them outside about the unusual
productivity of the team, and get a real team spirit going.

I remember one team guy I had who could never for the life of him have
figured out WHAT to do, but once clearly directed, he could implement
it so fast it seemed like a magic trick.

Another of my angels was a guy I had to only explain the general
principles of what I considered a good solution, then he would
constantly come up with better ways to do things.

With a team, you have a hodge podge of skill sets. Part of the game of
being boss is giving people tasks they like and/or are good at.

The error I see bosses often make is over-using seniority to decide
who does what.

It always helpful to look at problems from the boss's view point if
you are an underling and from the underling's point of view if you are
the boss.

 

[Mike Schilling]

Eh. Both of these:

if (i > 5) {
return foo;
}

and

if (i>5)
{ return foo; }

become

if(i>5){return foo;}

when semantically-insignificant whitespace is eliminated and
semantically-significant whitespace (which would run keywords/
identifiers together or cause a // comment to run further if omitted)
is reduced to single spaces (linefeeds in the case of terminating a //
comment). (In this case the single space between "return" and "foo"
remains.)

And who is to determine what "semantically significant" whitespace is? It's
hardly the job of an SCM system.

 

[Roedy Green]

"The diff engine internal to Subversion can now ignore whitespace and
eol-style when computing the diff."

You also have false deltas of line breaks. I got in terrible trouble
circa 1990 working in a company that gave the junior guys tiny,
low-rest monitors and the old timers giant high-res ones. The old
timers liked small fonts and very long lines. The new boys could not
read such code and would introduce line breaks. This caused false
deltas and territorial growling.

You also have reflowing of Javadoc with Eclipse.

 

[Twisted]

And who is to determine what "semantically significant" whitespace is? It's
hardly the job of an SCM system.

Given that all the usual suspects (C, C++, and Java) treat whitespace
pretty much the same, and source files for these are by far the vast
majority of everything that ever gets checked into these repositories,
it doesn't seem unreasonable for "C/C++/Java awareness" to be in such
tools, certainly as a plugin or option. Basically, it can just
recognize these files by extension (.c, .cc, .cpp, .h, .c+
+, .java ...) and ignore whitespace except between keywords/
identifiers (collapse to a single space), inside string literals
(leave it alone), and the first linefeed after a // comment (collapse
the contiguous whitespace there to just the linefeed).

I'm also obviously not suggesting it genuinely modify the file in the
manner described; just treat it as so modified for diff purposes.
(This can of course be implemented using a temporary copy that really
is modified that way.)

Actually what I'd like to see is pluggable diff engines (binding to
particular file types) so various language-aware diffs could be
included. A smart diff engine for a specific language could do a lot
more than ignore semantically-insignificant whitespace differences.
For example, if it borrowed from eclipse a little a Java-specialized
diff could tell whether two source files were semantically identical
modulo bigger changes, like if (foo) { bar(); } vs. if (foo) bar();
and reordered imports. Plug this into a future super-SVN and it gets
used to decide deltas on all .java files checked in. Presto: no more
complaints about false deltas.

As for the GUI builders, smarter parsing might be nice, so those can
read any code that instantiates and invokes setup-type methods on
Swing components and parse some sensible representation out of it.
Alternatively, the GUI builder should generate an intermediate format
that a standalone tool can convert to a Java source file; the
intermediate format is treated as a project source file and the Java
file as an object file. Much the way bison and yacc sources and output
get treated by the C community.