ORP Proposal Submission Tool
code standards #2
Replies: 2 comments 2 replies
-
I take it you mean column limit, just do what you think is sensible
Question for Paul I think
We use eslint - see here
Looking back at what I've written to date I've not been consistent with this, its not strictly necessary to write 'variable : type' as the type can be inferred. I usually specify the type if I think it lends clarity to the code.
Best practices would have use document all functions but its just sooo tedious and the code is always self-documenting, right? :) I think Paul is in the process of generating some documentation for the API at least (which is Java and uses the '@operation' annotation). For the GUI maybe we should comment on the input parameters and return values for the exported functions at least? |
Beta Was this translation helpful? Give feedback.
-
|
On the 80 character limit for lines, to be clear I didn't want it being imposed as a hard limit. I get that "just do what you think is sensible" is vague and subject to opinion so I'll be more clear. What I meant was on modern monitors going up to 100-120 characters is fine so long as the code is readable. Again, "readable" is subject to opinion but having a hard limit of 80 characters feels unnecessarily restrictive (a hangover from punch cards and teletypewriters, technology moves on). Looking back through the code these limits are usually exceeded due to long string literals. However, (and I have just read this), you can use backticks (`) for block strings in Typescript, and a triple double-quote marks (""") for block strings in Java*, so perhaps we should do that. *apparently only for Java 15+ |
Beta Was this translation helpful? Give feedback.
-
|
so ill throw my 2 pence in here. But be aware that I'm only working from my personal experience, and don't want to force any issue. Whereas there is a argument of modern monitors going up to 100 or 120 chars. It misses the usage of those monitors. Especially with an IDEA based IDE (such as InjelliJ) where you can split your screen horizontally / vertically to see multiple files opened (or even the same file opened in different areas) on the same screen. At this point (and I'll admit, I use this functionality a lot, as you try to chase down interfaces, or separating out code, or just in this nexted function world, to try to keep track of the overarching code that's spread over many places, and so I suffer this more than most.) your screen real-estate drops to 1/2 of a "modern monitor" and therefore 80 chars brings you back into the realm of being able to see all the code without any horizontal scroll bar. Its not like I have small monitors, i have 2 27inch monitors. I've had peeps throw the argument back at me of "just get bigger monitors" but I feel that's kinda missing the point. But to show that your not alone, this is a discussion within the coding community that's been going back and forth for decades. pep8 still recommends 80 chars. And I have a gaming night on Thursday evenings with friends who worked for google in the past and now work for octopus energy and we have the same discussions occasionally. with not just me on this 80 bench. So both of us are not alone in this debate. lol. The other flip side view, which again, maybe my ... .training? experience? judgement? (a bet a bunch of this comes from John Latham teaching Java in my undergraduate days) is that if there is many indents (the rule of thumb i was .... taught? .... was if your going to have 3 to 4 or more indents, then you really should consider splitting out the code into functions. In this nested functions, react dynamic HTML world, it does seem that its very hard to limit to that level of depth. Just getting to the first seems to be 4 indents on many occasions, and I've tried a few times to break apart deep nested code out, with limited success here so far. But that's why you see some of the changes where i try to do so. And at that point, you actually get a lot of your 80 chars back, instead of losing like 20 to 30 chars to spaces as I see in this code-base quite a bit.
on the following extracts from @DJWalker42 statements. yep, I've learnt that those are the ones needed if you want to do .... i think the term is string interpolation.... where you want to fold variables into the string. But it does mean long strings can be spread over multiple lines as well.
its why I'm also a bit miffed that the dynamic html doesn't seem to like the html comments . But i'm also not sure yet if this is just InjelliJ being funny, or an actual issue yet. As Angular had separate html and typescript files, this is new to my exp. |
Beta Was this translation helpful? Give feedback.
-
|
and an extra i just realised when doing the merge. If you use the InjelliJ merge, where you get 3 columns, branch1, merged, brnach2. you will find it hard to see all the code without a horizontal bar when beyond 80 chars. As im finding right now. lol |
Beta Was this translation helpful? Give feedback.
-
Is there a line limit we're working towards? Id personally prefer 80 as it allows me to have a split screen in InjellIj and not have to scroll to see the entire code. But thats just my own preference
Is there any copy-write expectations for the code? as I've yet to see any files with copy-write at the top of the file.
Is there any conventions we're trying to work with (aka TSlint? Eslint?)?
Is there expectations in terms of type definitions? aka, variable: type
Is there any expectation of documenting the functions?
Beta Was this translation helpful? Give feedback.
All reactions