5 ms·
Code formatting should be a non-issue. The way it should work is that when loading a file, your editor formats the code the way you feel most comfortable workin
by kleiba 4y ago
Code formatting should be a non-issue. The way it should work is that when loading a file, your editor formats the code the way you feel most comfortable working with it. On save, it should be formatted according to the guidelines of the group who work together on the code (company guidelines).
Of course, that means that sometimes you have to look at code in the latter while you prefer the former. For instance, when you examine a merge conflict. But for the most part, in your everyday programming work, you only see code formatted the way you like.
Of course, this assumes that it's possible to programmatically translate between arbitrary different code styles. This is probably true when we're only talking about differences in whitespace, but the story become quite different when we also consider things like naming conventions (different case styles (underscore vs. CamelCase, first letter small vs. first letter big, etc.) and other things.
- qprofyeh 4y agoRight, not in all cases; the disclaimer at the end of your comment should be at the start.
- mtlmtlmtlmtl 4y agoCode style can be pretty damn gnarly to automate. Not sure if it's still the case, but the Linux kernel used to have a script checkpatch.pl that was a few thousand lines of Perl, dense with regex, to check that patches conform to kernel style guidelines. And those guidelines are basically just K&R C style. When I was a teenager I really wanted to get into contributing to the kernel, so I did this babby's first patch, fixing the code style for this rather large, extremely messy 3rd party driver in the tree. Must have taken me a couple days; hardly any single line conformed to the guidelines. Sent the patch in and Greg KH replied saying thanks and all, but we were planning on just deleting this driver anyway, so no merge. Somewhat embarassing intro to open source contribution :D
- chrisan 4y agoDid you mean code style automation back then? Today's code style automation seems pretty solid.
- mtlmtlmtlmtl 4y agoNo idea what they do in the kernel now, but back then there was no automation, just that giant perl script that told you all the places where the style diverged from guidelines.
- MrJohz 4y agoI don't know about the Linux codebase either, but a lot of languages these days tend to have an CST-based formatter - given a syntactically correct but arbitrarily formatted file, it will essentially rewrite it into a standardised form. There's a lot of cleverness going on on top of that - using the context of the code to format things in different ways - but the core idea is generally to parse the code and then format that, rather than apply purely text-based rules. The benefit of this is that it almost cannot go wrong (unlike older formatters which might stumble over a line of code and accidentally write invalid or incorrect code). The disadvantage is that there are usually fewer configuration options, so if you don't like the formatting, you might just be stuck with it anyway.
- mtlmtlmtlmtl 4y agoYeah, rustfmt, gofmt etc is wonderful. Definitely been a lot of progress on this lately, with more modern languages anyway.
- yencabulator 4y agoMeanwhile, Go has essentially solved the problem, and Rust copied the idea. Neither of those languages need to bother humans with the details of exact code layout. The post-C world is a lot better.
- al2o3cr 4y agoThe way it should work is that when loading a file, your editor formats the code the way you feel most comfortable working with it. This doesn't seem practical if you have to reconcile external sources of information with the file - for instance, if you're looking at line numbers in a stack trace from production.
- wizofaus 4y agoIn principle even that could be solved with better tools (source map files and the like), but I agree, until such tools are universally adopted we're probably stuck with having to work with and store the same formatted code. As it is though correlating line numbers from production logs with current source is often an inexact science due to optimisations or difficulties retrieving the exact same version of the code that was used to produce the build (either because you can't find out the exact build number, or because the correlation between commit hash and build number got lost somewhere, etc.).
- kleiba 4y agoThat particular case (line numbers) is solvable quite easily in theory. But like I mentioned before, there are other problems - if the automatic reformatting includes more than just fiddling with whitespace.
- kmoser 4y agoTo expand further out: the reason this is a problem to begin with is that virtually all programming languages involve a compiler or interpreter parsing a textfile which humans (with the aid of IDEs) must laboriously maintain. Instead of arguing about code format styles, why not change our languages (or at the very least development environments) so that a list (for example) gets parsed, analyzed, and turned into an internal object, and doesn't remain merely a "dead" string of characters. Once lists are "objectified", we should be using tools to modify those objects (similar to how you'd add/remove rows from a spreadsheet, or edit the DOM in your browser's dev tools). How those objects get presented visually to the programmer as source code is irrelevant at that point: Want to show the list a a single line of items concatenated with commas? No problem. Want to see each item on its own line, without commas? Sure. The visual representation of lists just become syntactic sugar, while the actual list itself is embedded in the development environment as an internal object, much as your HTML pages become parsed by the browser into the DOM which you can inspect and modify via the browser's dev tools. We should be coding to build "smart objects," not writing strings of text to be endlessly curated.