|
|||||
author | remove search highlighting | ||||
---|---|---|---|---|---|
posted: 1 Dec 2019 07:22 from: Graeme
click the date to link to this post click member name to view archived images |
In the November Coding Clips: Martin Wynne wrote: Hmm. That's worrying, because for me it is an order of magnitude the other way.Well, perhaps worrying, but not all that surprising (though I confess this is the first time I have seen this particular viewpoint!) I've been trying to work out why that might be. I think it's that if I see:hahaha - Well, an ingenious explanation, I have to say. However - there ARE three things on the line. The ':=' is NOT just punctuation. In fact it is arguably the most important of the three because it is the one that defines what kind of statement we have here. It is an assignment. Although you said "the variable and its value" there are in fact two values involved in this part of the code. The value of abc before the statement executes and the value after, and it is the ':=' which causes the replacement of one value with another. As you said it is the operator. Very different from the ; at the end of a line, for example, which I would agree is 'punctuation'. With the three components closed together, I have to look closely at the line to see that it is an assignment and not a numerical expression (abc-123) or a procedure call (abc_123). Your point about syntax highlighting is a very good one, and it does make the operator stand out in the editor ... but not in here ... and not if I print out the code so I can scribble on it (does anyone really do that any more?) And the example of the sentence with no spaces was intended only to demonstrate that spaces do help to highlight structure. ANYWAY ... I promised I would not talk about specific formatting points. I am so clearly right about this that I don't see how anyone could possibly disagree! Which is great ... EXCEPT ... you DO disagree, and are just as totally convinced by your way of doing things. hahahaha And therein lies the real problem. We can't BOTH be right. But actually I think we are! Over the years I have been involved in literally scores of such discussions on formatting for over a dozen languages, and the conclusion I have come to is that there IS no logical justification for these views. It is fundamentally a matter of taste, normally re-inforced by familiarity, and all the "logical" arguments put forward are actually no such thing. They are post-justification for a previously determined view. My own cast-iron, how-could-you-possibly-dispute-it justifications included! This is why I call them 'religious' arguments. I know that NONE of the words I have written above, nor any of the thousands more I could write will change your feelings. The whole discussion is akin to you telling me that your favourite colour is green and me trying to convince you that you are wrong and blue is much better. But there is one thing that I can guarantee you. Absolutely 100%, cast-iron, totally, cross-my-heart guarantee. And that is this ... when we get a third contributor he will have a completely different view from either of us! hahaha And so to the point of all this ... You may have heard of the Go programming language, which was created by Google. In the Go community nobody ever talks about formatting. Not ever. It is a completely non-existent topic. The reason for this is that the compiler team also produced a code formatter which sits with the compiler and other tools and which everyone uses. It appears to be unthinkable to Go developers not to format their code using it. Now, it is almost something of a joke in that community that nobody likes what it does - at least not completely. There are some good bits and some bad bits, but of course nobody agrees on what the good and bad bits actually are! But what they all DO agree on is that standardisation is the most important thing, and so it is at once universally disliked and universally accepted. As you probably know, Lazarus provides easy (integrated) access to a code formatter called Jedi. I have glanced at the output and it looks acceptable, but even with a quick glance I saw a couple of things I would not do myself. I could not say I particularly like what it does. And I am pretty sure you will not like it either. But that is not the point. It provides consistency, and in a multi-contributor environment that is more valuable than anything else. The main points are:
Cheers, graeme PS Clearly that was only an example. I hope it is obvious to all that blue IS better than green. |
||||
posted: 1 Dec 2019 22:39 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, I'm not convinced that my argument is simply post-justification of a mere personal preference. However, I'm not going to continue this discussion because I suspect it is counter-productive. We need to encourage more folks to join in the coding fun for both TemplotMEC and Templot3, not put them off. I have written a utility exe which will strip out the spaces from .pas files while I work on them, and put them back before I post them. This should keep everyone happy, and also allows all the old existing files to be similarly updated. If anyone else shares my brain functioning and finds wide-spaced operators difficult to read, I will happily make the utility available to them. I think you over estimate my knowledge of the IT world. I had no knowledge of Jedi, and I know GO only as a fiendish board game. If you think either of these can help us, by all means go ahead with whatever is needed. cheers, Martin. |
||||
posted: 2 Dec 2019 06:58 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: However, I'm not going to continue this discussion because I suspect it is counter-productive.Yes indeed! And here we are in complete agreement. The one universal truth about formatting discussions is that they are a waste of time. I have written a utility exe which will strip out the spaces from .pas files while I work on them, and put them back before I post them.Perfect. And this is exactly how I believe we should work:
I think you over estimate my knowledge of the IT world. I had no knowledge of Jedi, and I know GO only as a fiendish board game.Hahahaha - no knowledge needed really, over and above what I said. Go is a programming language. The important thing is that their community has a standard format defined, as described above. Jedi is (or should be) already there as part of your Lazarus installation, accessed under Source>JEDI Code Format> ... menu item. My suggestion is that since that is available to everyone, built into Lazarus (and therefore, I suppose, arguably some kind of standard) that we adopt that as our 'standard' form for Templot. That should also suppress many of the spurious diffs which result from pure format shuffling. Cheers, Graeme |
||||
posted: 2 Dec 2019 09:42 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote:Jedi is (or should be) already there as part of your Lazarus installation, accessed under Source>JEDI Code Format> ... menu item. My suggestion is that since that is available to everyone, built into Lazarus (and therefore, I suppose, arguably some kind of standard) that we adopt that as our 'standard' form for Templot.Hi Graeme, Ah yes -- I now remember looking at that menu when I first started using Lazarus. Under About it says: Version 2.44 My red. From which I assumed that its purpose was to convert code written in Lazarus for use in Delphi. Also that it was 10 years old and likely to be out-of-date for modern versions of Lazarus. Also "make readable" is a joke for me, because having now tried it on a couple of files it does the exact opposite. Look at this for example then begin if p2.x = def_req then p2.X := rings[ring_list_index, 0]; if p2.y = def_req then p2.y := rings[ring_list_index, 1]; end else begin if p2.x = def_req then p2.X := screenx / 2; // arbitrary.. if p2.y = def_req then p2.y := screeny / 2; end; Unnecessary line-wrapping, thens and elses all mixed up, no idea which else goes with which then, and assignment operators lined up with conditional operators to cause maximum chances of misreading. Compare with my original: then begin if p2.x=def_req then p2.X:=rings[ring_list_index,0]; if p2.y=def_req then p2.y:=rings[ring_list_index,1]; end else begin if p2.x=def_req then p2.X:=screenx/2; // arbitrary.. if p2.y=def_req then p2.y:=screeny/2; end; However, if you think we should use JEDI before posting files I'm happy to go along with that. Anything to keep folks quiet. In passing I discover that it makes 50% of the utility I wrote yesterday unnecessary. On the other hand I can develop the first half to deal with more than just the spaced operators -- getting thens and elses lined up with clear space under them being a primary requirement to "make readable" for me! cheers, Martin. |
||||
posted: 2 Dec 2019 15:59 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: From which I assumed that its purpose was to convert code written in Lazarus for use in Delphi. Also that it was 10 years old and likely to be out-of-date for modern versions of Lazarus. Hi Martin, I think originally it was actually written for (and probably by) Delphi programmers to reformat their code. Well that was how i read it anyway. I thought it had just been grabbed by Lazarus project and re-purposed. I guess if the (pascal) language spec has not changed in a while there is no great need for the formatter to change, but let me look into it a bit more. But oh my gosh that code. I know I said it does not matter if we like it or not, but that is just UGLY! I would be embarrassed to use that as our standard. I still like the idea of a standard version, with a tool to support it, but this is not what I was hoping for. I suggest do nothing for now and let me look around a bit and see what I can discover. Cheers, graeme |
||||
Last edited on 2 Dec 2019 16:00 by Graeme |
|||||
posted: 3 Dec 2019 07:50 from: Graeme
click the date to link to this post click member name to view archived images |
Hi Martin, Well I have managed to tweak the output from Jedi a bit to produce something I think is ... well not unreasonable, anyway. At least it has got rid of many of the single word lines that looked so ugly (and illogical) to my eyes. On the basis that you have spaces under control I concentrated on the newlines and alignment. The 'end's do not line up with 'begin's the way you do it - I am not sure we will get a reformatter which does that - but at least they line up with what seems to me to be the 'owner' of the block (i.e. the 'if', 'else', 'case', or whatever). This is anyway how it would work in most other languages. (Yes, I know we are not using other languages , but it will at least have a familiar feel for most newcomers.) Anyway, the procedure I wrote for showing switch info comes out looking like this ...
Not perfect by any means (certainly not your 'Bingo!' moment) but I could live with it. If you want to try on a bigger sample, copy the attached file (with change of extension!) into your equivalent of C:\Documents and Settings\graeme\Local Settings\Application Data\lazarus\jcfsettings.cfg The example you gave is always going to be a hard one because a human eye will always be able to pick out cases where fortuitous similarity of lines of code make it worth breaking the rules. In that example, the 'if' statements looked so much better continued on one line. Under these settings, that example looks like this:
Again, not perfect, but reasonable, I think. Certainly a hell of a lot better than the default settings What do you think? Is this getting to acceptable yet? Cheers, Graeme |
||||
Attachment: attach_2948_3564_jcfsettings.txt 4 | |||||
Last edited on 3 Dec 2019 08:39 by Graeme |
|||||
posted: 3 Dec 2019 12:49 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, Many thanks for doing that. Yes I can live with that. I might even get to like it in time. I think it is important to see what it looks like with syntax highlighting, because in practice that how it is almost always viewed: 2_030735_420000000.png I confess it is unnerving to see an else and not be able to glance vertically above it to find the then. For one thing you don't know how far back to look, a few lines or several pages? One change I would prefer if it's possible, would be a blank line below "procedure..."/"function..."? You probably noticed that I already sometimes put ends below a block rather than strictly below the begin. But in that case I often comment the end; to indicate what it is the end of. For example with bananas do begin if ripe=True then eat_now else keep; end;//with or for n:=0 to eggs_list.Count-1 do begin if eggs_list[n]='' then CONTINUE else begin with eggs_list[n] do begin fry_it; eat_it; end;//with end; end;//next Can Jedi actually modify the code by adding such comments to end;s? cheers, Martin. |
||||
posted: 3 Dec 2019 21:26 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, I found the Jedi "Clarify" (!) settings thanks, and had a play with the indenting and line feeds. I got your code looking more to my liking with plenty of white space below if and above else so I can glance up and down between them without any eyeball obstructions. Likewise between begin and end: 2_031603_070000000.png However, when I tried the same settings on some of the other units it produced excessive amounts of white space indenting: 2_031612_350000000.png So I'm in two minds about the whole thing. I think I will write my stuff in my own way, and leave you (and others?) to set up this Jedi stuff any way you wish, and I will happily apply it to my code before posting it. It's all getting a bit much to think about on top of Templot2 and Templot3 and supporting users -- there's a request on RMweb tonight for help with setting Templot timber spacings for Swiss railways. Plus another release needed for Templot2 after a bug fix this afternoon. Feeling a bit weary today. cheers, Martin. |
||||
posted: 4 Dec 2019 02:16 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Yes I can live with that. I might even get to like it in time.I say! Steady on, old chap! hahaha I confess it is unnerving to see an else and not be able to glance vertically above it to find the then. For one thing you don't know how far back to look, a few lines or several pages?Yes, you are now looking back for the corresponding if, rather than the then - but it's just something you get used to. It should be easy to spot, though, as it should be just the previous thing at the same indentation level. Some editors actually provide faint vertical lines on the left showing each level of indentation, which makes it a doddle, but Lazarus is not one of them Perhaps using 3 or 4 spaces for indentation would make it more obvious? (I generally use 4 but I noticed that you had used 2 quite a lot, so I left Lazarus set at 2.) One change I would prefer if it's possible, would be a blank line below "procedure..."/"function..."?There is an option to insert above these headers, but not below. I DID find a setting which removes blank lines above, so we could turn that off. What I would like to see is a way of inserting the comment line of underscores that you have before each procedure, which is another thing I normally do, and I find it helps enormously. Again, no dice in Jedi. You probably noticed that I already sometimes put ends below a block rather than strictly below the begin. But in that case I often comment the end; to indicate what it is the end of. For exampleThis is actually the kind of end indentation with which I am most familiar (as you probably gathered ). I have also used this kind of commenting in the past with languages which use end to terminate just about everything. Sadly, Jedi will not insert such comments for us. But again, the beauty of this kind of indentation is that the opening keyword is just the previous thing at the same level. Cheers, graeme |
||||
posted: 4 Dec 2019 02:55 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: So I'm in two minds about the whole thing.I think I liked "... I might even get used to it" better. I think I will write my stuff in my own way, and leave you (and others?) to set up this Jedi stuff any way you wish, and I will happily apply it to my code before posting it.Well, you need to be comfortable with your work flow, so if that's the best way... Jedi could perhaps help you in this regard. If we have one 'standard' set of settings that we use for publication and a private set that adjusts to our individual preferences. Just a thought. I have make the tweaks I mentioned earlier and attached a new version of the config file below that we can use as the 'standard'. As you will see, I suggest that we call that file 'templot-jcfsettings.cfg' so we are not overwriting the delivered settings, and then we can each have a 'graeme.cfg', 'martin.cfg', or whatever. Also, we should check templot-jcfsettings.cfg into the source tree somewhere so that it is under version control, and anybody who gets the Templot source also gets a copy of the file. It may be a good idea to try to finish any work you have in progress before applying a global reformat, and post the reformatting as a change in it's own right. Any other changes in the same release will be buried in the diff tsunami! I don't have much that I need to keep, so I will manually copy my diffs over once you release the reformatted version. It's all getting a bit much to think about on top of Templot2 and Templot3 and supporting users -- there's a request on RMweb tonight for help with setting Templot timber spacings for Swiss railways. Plus another release needed for Templot2 after a bug fix this afternoon. Feeling a bit weary today.Yes, it is a lot on top of your 'day job'. I wish I could do more to help. Cheers, graeme |
||||
Attachment: attach_2950_3564_templot-jcfsettings.txt 0 | |||||
posted: 4 Dec 2019 05:07 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, Thanks. I've rather lost track of how we got into this. We do have the existing units, is it essential that they be changed? Anyone writing new stuff can clearly use any style they prefer, the only really significant point being that it compiles without errors and works. Changing the subject, did we follow up on my previous comments? What I'm finding very difficult to fathom is how to merge the units together? While you have been making changes to these units, I have also been making changes to some of them. Which means we now have 3 versions of each file: We don't currently have an updated set of files on SourceForge with some of the recent changes, however formatted. Anyone coming fresh to this hasn't currently got a starting point, which makes it difficult to encourage others to join in. cheers, Martin. |
||||
posted: 4 Dec 2019 05:43 from: Martin Wynne
click the date to link to this post click member name to view archived images |
p.s. Graeme, Is there a mechanism in the editor to do something like this: In base_unit.pas: end; //________________________________________________ INSERT FILE graeme_stuff_29.txt //________________________________________________ INSERT FILE martin_stuff_17.txt //________________________________________________ procedure more_base_code(..... If each contributor's stuff is contained in separate files, it would be much easier to do the updating and merging. They can't be full .pas files linked in the usual way by the compiler, this merging would take place in the editor before the compiler runs. Is this the sort of thing a Preprocessor function does? Or is there a compiler directive to do this? In some other compiling software I use for HTML I would write: #MERGE my_other_file.txt to do that. You have probably realised by now that you are not dealing with a fellow IT professional, but with someone who has ploughed his own furrow for decades. cheers, Martin. |
||||
posted: 4 Dec 2019 09:09 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: I've rather lost track of how we got into this.Hi Martin, Originally this started from a discussion on formatting, and my observation that
We do have the existing units, is it essential that they be changed?I would hesitate to say 'essential' to change the existing code base, in so far as the code runs fine without it. However, I would describe it as 'highly desirable' for the reasons mentioned above. A common format throughout the code base just makes life easier. On a purely practical note, at some stage one of us is bound to accidentally reformat an old module. It will be hard to go back, and any changes made will then be buried in the reformatting changes. if it is to be done at all, it will be much better just to do it all in one hit. Anyone writing new stuff can clearly use any style they prefer, the only really significant point being that it compiles without errors and works.Apart from 'working' from a user's perspective, the code needs to 'work' from a programmer's point of view, which involves being: - easy to read and understand - easy to modify and extend - easy to test etc. etc. all of which tend to be invisible to normal users, but important nevertheless, and most of these things are rooted in code which has consistent styling. Working on a code base which follows half a dozen different styles would be a nightmare. (or I should say IS a nightmare! I know. I have done it. ) Cheers, g PS I still think I preferred "... I might even get used to it" |
||||
posted: 4 Dec 2019 09:14 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Changing the subject, did we follow up on my previous comments? Hi Martin, No, not yet. I was expecting to get the formatting issue cleared away before going on to this. That has taken longer than I expected. I will try to get something out this evening. Cheers, graeme |
||||
posted: 4 Dec 2019 10:17 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Is there a mechanism in the editor to do something like this:Fair enough! There is almost certainly some sort of include mechanism in the compiler (few languages DON'T have one) but it would not be practical to use it for this purpose. For large changes it might work, but as changes get smaller it would be unworkable, I would think, and over time generate more problems than it solves. Cheers, graeme |
||||
Please read this important note about copyright: Unless stated otherwise, all the files submitted to this web site are copyright and the property of the respective contributor. You are welcome to use them for your own personal non-commercial purposes, and in your messages on this web site. If you want to publish any of this material elsewhere or use it commercially, you must first obtain the owner's permission to do so. |