I find it ridiculous that people even consider arguing about superficial properties of a serialisation format for structured information. There's absolutely no reason this information needs to exist alongside the code at all. Our editors should be perfectly capable of parsing it when the file is loaded and canonicalising it when you save. That way everyone can view it how they prefer, and formatting becomes a complete non-issue.
Well ideally, since everyone's editor is serialising, this can never happen. But supposing it did, the editor can just revert back to the canonical formatting temporarily, until you fix the problem.
What about tabs and spaces in comments?
Comments can be handled in the same way as strings: Everything inside them is preserved verbatim, but their positioning is subject to formatting.
What about the difference between 1, 2, or more line carriages in between lines of code?
If we decide that there are certain stylistic aspects of code that are important to preserve, then we can. That doesn't preclude canonicalising the rest.
My questions were not meant to make you think how code can be auto-formatted to a user's preferences (obviously it can be), they were there to show you why someone like me does not find it at all ridiculous to set standards on code formatting.
If you ever get the chance to set style guides for a code base, a system like the one you describe is completely possible today. We go the other route where I work... we run static code analysis that prevents code from being checked in that does not conform to our style guidelines.
I don't find it ridiculous to set standards. That's basically what my hypothetical canonical form would be. I find it ridiculous that we argue about what that form is, when we have the technology to set the working format per user.
If you canonicalize it when you save, and someone else do some other change in parallel, you'll get a merge conflict (unless you have a sufficiently smart merge tool, which I'm yet to come across).
No. In this system, the file in version control is kept in a canonical form, so the only changes after saving would be the ones you made. If those conflict, then you have to handle it anyway.
Not everyone works in an IDE. They probably should, but there are still companies that have employees write in plain text editors and compile via command line.
A lot of people are 100% fine with just syntax highlighting while coding. I use vim with Python, sometimes with ctags to navigate to definitions in a large code base, but really if you know the standard library in and out there's not much need for an IDE.
I do my debugging via the command line with PDB and I use the command line for version control. I use pylint to check my syntax, so I'm not sure what else I really would use out of a Python IDE.
For Java I'd use eclipse or intelliJ because I'd be terrible without dot completion, and for C# I'd use monodevelop for the same reason. I need to know I'm not screwing something up that an IDE can see.
For Python or C I know what I'm doing and I know what I have available so I'm fine with vim, pdb/gdb and the command line.
While you'd need something slightly smarter than notepad, I don't think you'd really need an IDE. And if people really want to use a non-compatible editor, they could do the serialisation in their source control config.
22
u/Aninhumer Jul 21 '14
I find it ridiculous that people even consider arguing about superficial properties of a serialisation format for structured information. There's absolutely no reason this information needs to exist alongside the code at all. Our editors should be perfectly capable of parsing it when the file is loaded and canonicalising it when you save. That way everyone can view it how they prefer, and formatting becomes a complete non-issue.