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

QuickNick wrote: Having edited and created templates I can see both sides of the "named parsers" debate ...
 * It's so much easier to find the piece of information if it has a name, looking through a line of templated data separated only by pipe | symbols can be quite confusing.
 * It's really useful when you want to change a template, e.g. to add another field, you just stick it in there ... so much easier than having to re-number all your existing fields so the data is grouped logically OR adding it at the end where it's not grouped logically.
 * Placing them on separate lines makes reading and editing easier BUT makes scrolling through a long list (e.g. the Cars page, 199 x 10+ fields) rather painful ... and, ironically, easier to miss something on a smaller-screened mobile device which this change is meant to benefit!

As Dave (good to see that you're still here!) wrote, swings and roundabouts. Inertia, most people don't like change, having to learn something new. I think it's a good thing as long as the old method continues to work ... I really don't want to have to rewrite all my templates and PQ scripts!

I think there should be a RR3 Wiki naming policy e.g. proper/meaningful names, capitalised words, no spacing, etc ... CarID. Maybe a page with the list of parser/field names, edited as new names are added. Just a few, for example, to get us started! I don't have an issue with the Named Parsers. I think they are beneficial, though after a few times of editing, you kind of remember what field is what and what the abbreviations are in the old format too.
 * Car
 * CarID
 * CarAlt
 * PR
 * PRbase
 * PRcash ... $ can causes issues with some PQ functions!
 * PRfull
 * Series
 * SeriesAbbr

When I used to write my own code, I spent a lot of time at the start of a project to researches best practices for naming, and I would always document. Sometimes comments were more lines than the code itself, 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?' spending the time at the front end to come up with meaningful naming is very important, so I agree with what you are proposing.

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.

And while I can appreciate the argument of making the code more mobile friendly, who is doing any serious edits on a mobile device? If they are working on a tablet, then that gives enough screen real estate to work in a similar fashion to a computer. And why would we want to encourage edits from a phone? Data entry of any type on a phone is far more error prone and you have few if any of the benefits of Find or Replace or even easy Copy & Paste.