|
but, when you go to trial ... put on an acceptable face.
better yet ... develop disciplined habits of code-writing style that become so ingrained you use them without conscious effort. or ... use ReSharper
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
because brackets and statement ends deemed to difficult but making sure all lines in a if are same either tab or space is easier.
I genuinely don't know now, being more aware of neurodivergency and maybe typical do find statement ending characters more difficult then making sure is 4 spaces, and not a rogue tab due to copied code.
|
|
|
|
|
I don't care how it's formatted because if it's terrible I can fix it with a click.
The one exception being the lack of changing tab widths in VS Code. People that use 3 spaces for tabs can't sit at my table.
Real programmers use butterflies
|
|
|
|
|
I guess I'll have to sit at your feet then!
I use 3 spaces because 2 isn't enough, visually, unless a function is short. And 4 or more wastes horizontal space. I limit lines to 80 characters, which helps when looking at diffs and whatnot. My take is that a lot of code wastes horizontal space but uses vertical space too miserly.
|
|
|
|
|
Half the editors out there handle 3 space indents like garbage unless you go and change their settings.
Everyone is running at least 1080p now, which makes 80 column code something of an anachronism as far as I'm concerned. 80 column displays are so 1990s. Saving a few spaces in tabs isn't going to make or break anything on a modern display. YMMV.
Real programmers use butterflies
|
|
|
|
|
1990s? I started coding on 80-column punch cards where the last 8 columns were for sorting a dropped deck!
|
|
|
|
|
honey the codewitch wrote: 80 column displays are so 1990s. Not if you like to view two files side by side.
/ravi
|
|
|
|
|
Yes, that's what I was getting at with diffs, but windiff or the VS GitHub plug-in rather than that Unix shite.
|
|
|
|
|
I'm on 4k. I put 'em side by side anyway.
Real programmers use butterflies
|
|
|
|
|
I have to use 150% scaling AND larger characters on 1920x1080... On a 22" monitor.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I have resolution envy.
/ravi
|
|
|
|
|
It does make working nicer, and I am glad to put the nightmare of multimonitor behind me.
I use a 55" at 4k and wall mounted it behind my workbench which doubles as a computer desk.
It cost some money to get it set up, but can recommend. It was worth it.
Real programmers use butterflies
|
|
|
|
|
I work with legacy code. In the beginning, it seems, the coders decided to keep some parts of code left justified. When I go into the files to update, it will not collapse properly. Sometimes 4000-5000 lines of code will not collapse and I scroll endlessly and ^f is my friend.
And let's talk about the use of tabs in place of spaces. Why is that not standard practice? It is clear that the various programmers had different notions of how many spaces constitute a nested block, though I'm sure that to the one beginning the thing, it made perfect sense. Why is this important? Git diff presents very odd spacing in additions to the block that use a different white space solution. It is confusing to have bits of a nested block be indented differently.
Ranting aside, I have made my peace with it and can duplicate the nested white spaces much more efficiently now, but you did ask
|
|
|
|
|
I really don't care how code is formatted - It'll be formatted how I like it when I'm finished with it!!
|
|
|
|
|
Use Code Beautifiers as needed.
|
|
|
|
|
Programmers who cannot help out of this with the help of Beautifiers are not programmers...
... if I think again about it... yes they are programmers, but only machines who have no idea about what there program should solve. For them the most important is that the code is properly formatted
|
|
|
|
|
An extreme example of an unformatted code file is a minified JavaScript file.
Unreadable.
|
|
|
|
|
Amarnath S wrote: Unreadable. It is formatted though.
No spaces, no new lines, one-letter variable names (then two, three, etc.), perhaps functions are formatted into arrow-functions where possible, etc. etc.
|
|
|
|
|
|
Ha! I just came here to add that option, but you were first.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Because it helps us read the code!
And since the average programmer spends a lot more time reading than writing code, reading it should be as easy as possible.
People who answered "however you want" or "I don't care" are selling themselves, and their team, short!
You wouldn't want a book to be formatted however.
You also wouldn't want a restaurant menu formatted however.
You probably care about formatting in other communication, like e-mails, letters, etc.
So why should you not care about code which is hard enough to read even when properly formatted.
I prefer a generally acceptable format for a language, that way it's easier when you switch jobs, teams, projects, etc.
I'm not sure why teams feel the need to override such formats, but if there's a specific format in a company or team, stick to that.
It's never too late to keep sticking to formats, or switch to a more readable format, even when the rest of a project is not properly formatted.
|
|
|
|
|
Consistently formatted code when working on a project with other developers is important to me, it helps with merges and version history as well. I use CodeMaid for helping me to do this.
|
|
|
|
|
Right Click|Format Document
done.
I don't care how your code is formatted. I'll just reformat it.
Real programmers use butterflies
|
|
|
|
|
Yeah, that usually works (unless you're not using VS).
However, this really messes up your source control because everything may have changed.
I have this with a customer of mine who uses an indentation of two spaces instead of the default.
Whenever he or I format a file our compare tools just show one big red square (deleted) followed by a big green square (added).
What the other actually changed will forever be a mystery...
Besides, I don't want to battle with coworkers over formatting.
We have much better things to do (like procrastinating on CP)
|
|
|
|
|
When I get unsatisfactorily formatted code, I'll do a "reformat run", and format every single document on a single check in to keep the source control churn to a minimum. It's a minor inconvenience. In practice I don't like your formatting. I don't like that person's formatting over there, either. I don't even like my formatting half the time. I'm picky*, but also lazy. So I just expect reformatting as part of the development process.
*And I get pickier when I'm on a team - at that point I'll go in and change my VS autoformatting settings to match the in house style.
Real programmers use butterflies
|
|
|
|