On 24/10/11 14:05, Glenn Adams wrote: > On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl <georg.datt...@geneon.de>wrote: > >> Hello Glenn, >> >>> (2) there is no standard for symbol length documented in FOP practice >>> or enforced by checkstyle; I decline to exchange my choice of symbols >>> with longer symbols simply because you prefer it that way; I have >>> offered to add comments to my uses, and that is the most I'm willing >>> to do to address this matter; >> >> You probably spent more years programming than I am alive, so please excuse >> me if that’s a stupid question: What is the reasoning/advantage behind those >> short variable names? >> > > First, I don't use short names everywhere. Mostly I just use in local > variables, but generally not as class variables. > > Second, I was trained in Physics and Mathematics, which uses short variable > names (E = M C ^ 2).
Welcome to the Computer Science world, where longer variable names rule because they allow to make a program easier to understand and maintain. When I read the paper about the total-fit algorithm for breaking paragraphs into line, I found that the numerous one-letter variable names were an impediment to understanding it. It was difficult to remember what concept each variable was associated to. > Third, I started programming in the 1960s with BAL 360, APL, then FORTRAN > IV. We use short names there. Yes, it is very fortunate that the computer world has learnt from those old days, and moved on to embrace better programming practices. > Fourth, I happen to have a good memory and I have no trouble remembering the > meaning of variable names. > > Fifth, I find that short names prevents making lines too long and gives me > more room for comments. By putting only one statement per line it is rare to bump into the 100 characters per line limit. > Sixth, I am going to be maintaining this code. If anyone has a problem with > specific code during a merge or regression, they merely need ask me. As Simon has already pointed out, this is not the way it should be in an open-source project. > Seventh, that's just my style, and I assert it is as valid as doing it with > long names. When I joined the FOP project, I adjusted my style to follow the project’s practices. It seemed obvious to me to do so, because a consistent style within a project avoids unnecessary distraction when wandering through its different parts. I would expect any contributor to do the same. > Eighth, asking me to adhere to an undocumented convention that is not > otherwise enforced, and for which there is no evidence or analysis of having > been previously followed in FOP contributions is unwarranted. There is no documented convention simply because it has never occurred to anybody in the past that short variable names could be an option. This is this kind of unwritten convention that everybody takes for granted. > Ninth, spending time changing variable names is a waste of time when I could > be working on adding support for other scripts. So someone else is going to have to waste all that time converting those names into more readable ones. That’s a bit unfair, isn’t it? > I can probably throw in a few more random reasons, but this should be > sufficient. > > I've offered to add comments, take it or leave it. Would you at least agree to use more readable variable names in new code? That would be of great help to people who will get involved in the Bidi stuff in the future. Thanks, Vincent
