-
Notifications
You must be signed in to change notification settings - Fork 518
Feature/coding style #1579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/coding style #1579
Conversation
Thanks, my fingers don't work as well as they used to, so I appreciate you picking up typos like this! Co-authored-by: Donghyun Kim <[email protected]>
Co-authored-by: Donghyun Kim <[email protected]>
Hehehe, good catch, thanks! 5:D Co-authored-by: Donghyun Kim <[email protected]>
I'm not sure if my comments are coding style... What about suggestions for variables names for common things? e.g. a What about the order of variables for a function, e.g. context first, then layer/symbol names, then other bits. It's almost always in that kind of order I think? What about suggesting passing things like layers by name rather than the actual objects. You touch on these in the classmethods part, but maybe suggest it for everything? |
… f-string modifiers over separate calls
I don't know if this is the best place for this or not, but this scenario has cropped up a couple of times now and it's worth paying attention to during dev + code review. We'll often use lists/sets/dicts to store offsets that we've already seen, but what ends up getting added is not a simple primitive but an |
Sure, feel free to add commits to the branch adding appropriate sections? It's not supposed to be an edict from on high, it's supposed to be a collaborative effort we all add to to get right... 5:) |
Doesn't feel like anyone's had massive issues with this, so I'm going to merge it in and then people can PR changes they may want... |
As part of #1578 I figured we should really get the coding style more front and center. This is where we can work together on a branch to get it in shape and make sure everyone's happy. We should include reasoning behind our decisions to avoid arguing or bikeshedding. Even if it ends up in here, it doesn't mean anything's set in stone, just that that's how we do it for now, but if there's a good reason to change in the future, then we can revise it...
If you all could take a look at it and put in anything we tend to do that I've forgotten to note down, or things you don't agree with (or that we don't do or stuff you think we should do), at least it'll be recorded and then we can discuss it to reach a consensus. 5:)