Thread:Amrosa/@comment-25956839-20171127182643/@comment-28169398-20171128163455

QuickNick wrote: Amrosa wrote: ... but if you want the code to be useful to others, or even to yourself 6 months down the line when you open it up and think, 'I wrote that?' Been there!

Amrosa wrote: However, I think scrolling is more problematic. It takes more time to find the place you are looking for and I think it adds more opportunity of errors. You may think you are updating data for one record when you actually scrolled one or two places too far and are now in the next record. Totally agree. I think a compromise of named parsers with a table/template line per line makes a lot more sense. I think (Michael told me) that they don't have to be on separate lines, it's just desirable. That said, adding another parser detail on a new line is much easier than inserting into the line BUT with named parsers the order is irrelevant so you can just add it to the end of the line (before the closing }} brackets). Either way works. While I know Parsers allow for free form entry in between braces, I think it is bad practice to not enforce a strict order within the "sentence." That would be when it would become a real nightmare to edit single lines. At least if I know that Variant= will be somewhere in the middle of the sentence, I can quickly scan there and find it, or add it. If it is at the beginning in on event, at the end in another, 2/3rds of the way through in a third, that is when it becomes painful to edit.

For rarely used parsers, such as Daylight= and RollingStart=, I would say those should always go at the end of the sentence, just before Version= }}