Hi, On Sun, 2006-11-26 at 15:41 +0100, gg@xxxxxxxxxxx wrote: > please, make code readable with explicit variable names and named > constants. Lines like the following are very economical on file size but > very wasteful on human time for anyone who did not write the code: > > dv = du + w[i]; > > looks like it came straight of a page of math text book on matrix algebra > (and probably did). But once out of that context it becomes meaningless. Prepending a variable with d to indicate some sort of difference is well-established. While I agree that a lot of code could be improved, I don't think that delta_v is in any way better than dv. Fortunately, most of the ugly code is in the lower parts of the core. It's the old code that is going to be rewritten with GEGL sooner or later. > I recently submitted a patch were I had cleaned up the code and renamed > this bytes_pp , this oddly met with some resistance and finally got > accepted as bpp. Fine it's a great improvement, although I was a bit > dismayed that this sort of change needs debating. > Longer names make longer lines. Especially if comments are added. Another > patch I submitted recently got the comment truncated to the point were it > was misleading rather then helpful just because it went a few chars over > the manditory line limit. I asked you to correct that in your next patch. A comment can easily extend over multiple lines. With longer lines, two editor windows won't fit next to each other any longer. > I think the rigid coding guide of 80 chars should be re-evaluted. If code gets longer than 80 chars a line, something is wrong anyway. It should probably be rewritten because obviously it's too deeply nested. > If the idea gets a favourable reception I will submit a short text for > inclusion in Hackordnung advising on readability and variable naming. > Current guidelines seem mainly restricted to defining format. Not sure if adding anything there along those lines is going to help. Almost all that ugly code that you are refering to is much older than the Hackordnung anyway. The newer parts are all quite readable. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
