Re: PgJDBC: code reformat - Mailing list pgsql-jdbc

On 29/12/15 01:22, Dave Cramer wrote:
>
>     On 28/12/15 04:01, Vladimir Sitnikov wrote:
>
[...]
>
>
>         Compare this one:
>
https://github.com/pgjdbc/pgjdbc/blob/197175039068446a15c30d2b5e949f1eae08515d/pgjdbc/src/main/java/org/postgresql/jdbc/PgResultSet.java#L2462-L2512
>         with this one:
>
https://github.com/pgjdbc/pgjdbc/blob/197175039068446a15c30d2b5e949f1eae08515d/pgjdbc/src/main/java/org/postgresql/core/v3/QueryExecutorImpl.java#L264-L311
>
>         Do you see how QueryExecutorImpl.java#L264-L311 is much readable?
>
>     No.  Possibly I'm not seeing the code you want me too?
>
> Same problem here, one of them shows comments. I believe the first one.

Comments can be good, but are orthogonal to the question of code style.

>
>     I would add more blank lines for readability, but would eliminate
>     blank lines after opening brackets and before closing brackets.
>
>     Also would simplify lines to ease readability and improve ability
>     to debug, eg
>
>
> So there are very good reasons in Java not to do what you are
> proposing below. Mostly because it creates objects which have to be
> garbage collected.

Hmm...

I suspected that the Just-in-Time compiler (I knew from my previous
research that they are truly vicious when it comes to optimisation!!!)
would end with up with the same code, and actually ran a test that
proved it.

I ran multiple loops with and without an intermediate variable, the
variation between runs of the same type was vastly greater than the
difference in the means - each run was about 34 seconds.

I looked at the output of -XX:CompileCommand=print and found that the
optimised code was identical, even though the initial byte code was
different!

In essence, adding an intermediate variable makes no difference in the
long run.

So making code more readable does NOT lead to any noticeable reduction
in performance when the coded is executed many times.  I strongly
suspect that the difference in code executed just once in a run, would
be insignificant compared to the noise in measuring the run times in
practice.

Therefore, since programmer time is costly, it make more sense to put
effort into code readability, than into premature micro optimisations.
Which is basically what most texts books on optimisation say.

If you want, I can send you the gory details in an OpenDocument file
(e.g. one produced natively by LibreOffice).

> While I agree that it is more readable. I think driver code has a
> responsibility to be as curt as possible with respect to creating objects.

In practice, the changes I have suggested do not have that problem.

>     Would rewrite:
>         ((V3ParameterList) parameterList).checkAllParametersSet();
>     as
>     V3ParameterList v3ParameterList =(V3ParameterList) parameterList;
>     v3ParameterList.checkAllParametersSet();
>
>
>     and would rewrite:
>         if ((flags &QueryExecutor.QUERY_SUPPRESS_BEGIN)
>     !=0||protoConnection.getTransactionState()
>     !=ProtocolConnection.TRANSACTION_IDLE)
>     as
>         boolean abc =(flags &QueryExecutor.QUERY_SUPPRESS_BEGIN) !=0;
>         boolean xyz = protoConnection.getTransactionState()
>     !=ProtocolConnection.TRANSACTION_IDLE;
>         if (abc||xyz)
>     (except I would use more meaningful names for 'abc' & 'xyz' above!)
>
>     I also only ever have one return per method, as that makes it
>     easier to:
>         (1) understand
>         (2) maintain (add new code and/or change existing code)
>         (3) debug
>
>
>         PgResultSet#getFastLong is very hard to follow no matter which
>         way you
>         format the braces.
>         I believe, "readability" comes from proper segmentation (code
>         blocks
>         vs methods) and proper variable naming.
>
>
>
>
> Dave Cramer
>
> davec@postgresintl.com <mailto:davec@postgresintl.com>
> www.postgresintl.com <http://www.postgresintl.com/>
>