-
Notifications
You must be signed in to change notification settings - Fork 3
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
Coding style guide #22
Comments
@iteles I've adopted |
😝 It is better though! |
I've always preferred How can we even semicolons though? Why not Standard JS? https://github.com/feross/standard |
Come on ... 2-space indent isn't "dark side" |
Drama added for emphasis. I used to tab, as it seemed the semantically correct character for the job, and all my editors were smart enough to deal, and it gave the reader the freedom to set the indent depth as suited them. Then I started writing JS for a living, and ultimately I couldn't deal with being the only tabster in a space-bubble. The straw that broke the camels back was GitHub rendering tabs as 4 spaces which looks ridiculous with callback heavy code. That said, maybe that's a good thing, (i pathologically avoid nesting things as a side effect) and GH now deals with tabs sanely. Anyhoo, I space now. There is value in adopting the prevailing code style of the eco-system you plan to swim in, just to lower mental admin of jumping between projects. Defining a code style is a good exercise for someone learning to code, so you can all evaluate the tradeoffs. Maybe it's an exercise for the summer, rather than in place at the start? |
I have no problem with spaces, it's the lack of semicolons that freaks me out a little. I'm a fan of the pauses 🙈 |
Linked to dwyl/start-here#41 |
What's the best term for this 'style guide' thing so that I can create a repo and make a documented start? And should we have a repo for the visual style and a separate one for coding style? Will having them together actually make back-end developers more aware of the visual side of things (seeing as anyone focusing on the front-end will need to see both)? |
https://github.com/Flet/semistandard is a fork of standard with semicolons on top. (I do realize the irony of forking a standard and changing it). Everything else is the same |
Separate repos makes more sense to me. If I'm supposed to be looking for JS rules and start reading through visual style because it's there and I have a short attention span, something doesn't feel right.
Why not "visual style" and "coding style". I dig the explicitness. |
@FilWisher let a thousand standards bloom : https://github.com/JedWatson/happiness @iteles What does 'fully commented code' mean? 😟 I find comments tend to reduce readability, but have certainly struggled through code where a comment or two would have been immensely helpful. |
@FilWisher I take your point and I tend to agree, but I'm also curious about whether looking at a few of the visual pieces by default will give developers who focus exclusively on backend tasks a better view of how everything works together 😉 @rjmk Great point. I agree that that needs more explanation. We'll have a few examples, but it's mostly common sense, putting yourself in the shoes of the person who has to inherit your code. Usually whoever is QA'ing your code can help with this perspective (if they're good) - if they're asking 'what does this bit of your code do?' then you probably need a comment. |
@iteles agreed. 👍 |
…492f557661946eabebbc649d5c2c719ef as per dwyl/summer#22 (comment) and dwyl/start-here#53
I'm closing this issue for now as the style guide is an ongoing piece of work. All style guide issues can now be raised here ➡️ https://github.com/dwyl/style-guide |
_underscores_
for italic and @nelsonic uses*single asterisks*
)And many more including a guide for writing issues. Either way, this needs to be done by the summer.
The text was updated successfully, but these errors were encountered: