Talk:Bin given limits
Input data re-formatting?
Hi, I don't normally put so much data into a task description so took pains to carefully format it as 10 items by 20 lines. It has been reformatted as 20 items by 10 lines, which I personally like, but goes against the 80 character maximum line length guideline, (not rule), for idiomatically formatted Python code, (and may do the same for other languages too).
--Paddy3118 (talk) 05:47, 7 February 2021 (UTC)
- Insomnia. I thought the task description itself looked better. Then I worried people would hate me. I tried to make it so that each change is clearly labelled and would be individually undo-able. I forgot about the 80-char rule, my bad (pep8 does state that up to 99 is ok). Apart from Go at 112, I believe the other modified examples now have some lines in the 88 to 93 range. --Pete Lomax (talk) 06:01, 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 IFs 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). -- Gerard Schildberger (talk) 17:20, 7 February 2021 (UTC)