Talk:Bin given limits: Difference between revisions

→‎Input data re-formatting?: added some comments.
(→‎Input data re-formatting?: added some comments.)
 
Line 7:
:: (Shh, I prefer the change :-)
:: --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 06:24, 7 February 2021 (UTC)
 
 
::: One of the programming examples has the data formatted with a 171 byte-wide image,   and I have no issue with that.   It's nothing complicated to read, and being data,   there isn't anything complicated to assimilate.   But as far as the 80-character rule,   I don't see why data   (and especially comments)   can't exceed that even in normal circumstances.   Programming has come a long way since being limited to punched card images and/or terminals with an 80-byte width.   Reading code longer (wider) than a certain amount of bytes is normally a sensible idea   (and there are always exceptions),   and of course there are cases where compound '''IF'''s can be extended to multiple lines   (possibly with continuations, depending upon the computer programming language),   so there isn't a clear and concise rule what makes a computer language statement more or less readable than another,   not withstanding coding norms and some programming languages that use a lot of syntactic sugar and liberal use of blanks.   I used to program my REXX programs with statements (more or less) being contained within 38 bytes,   with comments almost invariably starting in column 40 through 80,   (essentially leaving 36 bytes for commentary within an 80-byte "card" image.   (For boxed comments, I used the entire coding width).   Then I started commenting almost all of the REXX statements   (and adding whitespace liberally to make perusing easier),   and it was clear that 38 columns wasn't going to cut it.   So I increased my coding-width acreage for comments to columns 50 through 90   (but it wasn't a hard and fast rule, however).   I like to indent compound statements and other coding grouping --- '''DO''' loops and '''DO''' groups,   '''SELECT''' groups (aka '''CASE'''),   and mostly,   nested '''DO''' loops.   Also, sometimes when the logic was hard to follow,   for instance,   '''IF --- THEN; ---ELSE'''   clauses.   I also like to eschew Egyptian indentation for '''DO''' groups and have the statements and '''END''' statement match the "start" of the '''DO''' group.   However, the one thing that I don't mind extending (width-wise) is '''data''',   there is nothing complicated about widening imbedded data within source code,   but when there is a "largish" amount of data,   I prefer to have that data in an external file and simply read in the data.   Some data would make sense in bringing it in-line,   such as almost never-changing data,   like US state names,   state abbreviations and capitals,   a list of the periodic table of the elements,  --- although the latter does get updated from time-to-time.   And Rhode Island citizens  ''did''  vote to change it's (official) state name   (it used to be:   Rhode Island and Providence Plantations,   but I don't know when it will become official).     -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:20, 7 February 2021 (UTC)