TABS. It is a question of #accessibility, you morons!
Death to #smartTabs (aka random haphazard inserts of spaces depending on the IDE at hand)!
#CodingStyle
Question ? what do you think about this style of coding. Is it readable enough ?
I've been using it a lot lately #PHP #codingstyle
Some great points, some not so great ones:
“My Favorite C Programming Practices” [2014], Malcolm Inglis (https://github.com/mcinglis/c-style).
Via HN: https://news.ycombinator.com/item?id=40409956
#C #Programming #CProgramming #Style #CodingStyle #Guidelines #BestPractices #C11 #C17 #C99
Fuck zodiac signs, tell me which name you'd choose
#codingstyle #programming
Finally started, including an editorconfig file as part of my checkins to make it easy for my team to stick to general indentation style. Should have done it a while ago. It would have saved me an hour of reformatting code to use two space indents. #codingstyle
https://editorconfig.org
Bisher den einzigen #CodingStyle Dissenz im Team gibt's bei:
Leerzeichen vor oder nach (cast) statements (von PSR/PER nicht abgedeckt):
if ((bool) $var)
if ((bool)$var)
funcyCall((string)$something, (float)'1.337', (array)$var);
Werden wir wohl einen Fight Rule Club aufmachen.
JavaScript/TypeScript getters and setters
#JavaScript #TypeScript #codingStyle #getters
Excited to apply these rules in my side projects. Have been generally following best practices so when I run dotnet-format, hopefully there won't be too many differences. (Best laid plans and all).
https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md
I'm #bored. Let's have a #flamewar about #codecomments.
There are those "YOU SHOULD NEVER WRITE COMMENTS, IF YOU NEED COMMENTS YOUR CODE SUCKS AND NEED REWRITING"
and then we have "You should comment *ALL* code *ALL* the time"
And then we have "You should write comments, if it makes sense and the code is non trivial"
Which camp are you in, and why?
Oh, boy... after over 25 years of C and C++ programming I'm starting to consider and use `goto` for reducing the redundancy in some cleanup-on-error sequences.
I don't know if I should happy or depressed about it. :P
I might as well conform to the Linux kernel coding guidelines (that mostly match my honed-over-the-years style).
Droid Sans Mono is my favorite font with 20 of font size.
I always followed linux kernel coding style because is without any doubt rational.
But on kotlin 80 row lenght is too short, like all bad languages that are based on multiple nested crap.
I raised row lenght to 120, this implies that you have atleast 2 monitor to work well, but for me is not a problem.
Coding style have just a task, make the code more readble, after read 24 hour, you know what I mean.
:blobheartcat:
I'm experimenting with a new #codingstyle: For every line of code there's a line blank following it.
Kind of looks like those Bills they bring before the US Congress.
Why do I like this #codingstyle so much?
https://www.reddit.com/r/ProgrammerHumor/comments/qhjthz/be_warned/
“John Carmack On Inlined Code” [2007 & 2014], Jonathan Blow (http://number-none.com/blow/john_carmack_on_inlined_code.html).
Via HN: https://news.ycombinator.com/item?id=25263488
#C #CPlusPlus #Programming #Bugs #Readability #Performance #Inlining #Optimization #CodingStyle
I've just discovered that ESLint's default is to *require* a space before the opening paren in a function definition. Admittedly I most recently came from C++ but this feels very backwards to me. Are there...reasons? As much as there ever are for style things?
I learned that spaces before paren in block statements in C++ was specifically to differentiate from function declarations/calls, so this default perplexes me.
Code is code and should be structured according to what it means not to how it looks. And let's also kill arbitrarily deep indents for visual alignment. Each new logical level should be one and just one level deeper.
Of course, a #CodingStyle that mandates 8-column indents (like #Linux) or one promoting very long names with calls chained together (a la #Java) will make this column-limit seem too restrictive.
However, such a coding-style is dooming you anyway for the use-cases above.
Reading code in a browser (more so on a mobile phone), coding on laptops, side-by-side tiling windows, three-way merges, aging eyes, neck-strain, comprehensibility, etc. _all_ benefit from shorter lines.
The age-old line-length issue in #programming - #LinusTorvalds weighs in (& FWIW, I disagree with him on this):
https://lkml.org/lkml/2020/5/29/1038
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst