3 ms·

The main problem with appealing to "best practices" is this: One man's best practice is another man's anti-pattern. Between semicolon-free folks and JavaScript

The main problem with appealing to "best practices" is this: One man's best practice is another man's anti-pattern. Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert? If Node.js is popular, does that mean that Isaac's comma-first style is "correct"? (https://gist.github.com/357981 https://gist.github.com/357981) In the absence of a quantitative engineering method with which to evaluate either approach, isn't it a purely personal and political choice?

j_baker 15y ago
You can't solve everything with numbers, and I say this as someone who believes very strongly in data-driven decision-making. Even given perfect data as far as what practices are more effective, you still have the problem of interpreting it. This adds its own layer of purely personal and political choices. My advice? Don't work with people whose best practices are your anti-patterns. Or at least strive to work with people who agree with you on a core set of principles. Or hell, work with people who agree with you on nothing. Just don't complain when you can't work with any of them. :-) And besides that, what's wrong with "purely personal and political choice[s]"? Being that I'm the person who's writing my code, I'm allowed to make a certain number of purely personal choices. That is, as long as I take into account the political consequences of doing so. Put another way, it's ok to have personal preferences, but you have to take other peoples' feelings into account too.
InclinedPlane 15y ago
The problem here is viewing software development as some sort of monolithic phenomenon. "Software development" is a crude moniker that covers an incredibly wide variety of efforts, varying in scale, detail, and significance across a much wider range than anything else we consider to be a single discipline. "Best practices" for development of an iphone game may not be the same as for flight software for an orbital rocket or for an international banking backbone. Edit: to use an analogy, imagine if all vehicle development was treated with the same terminology. Whether you're building helicopters, spacecraft, mass produced commuter cars, RC toys, nuclear powered submarines, formula 1 race cars, or tunnel boring machines: all of it is just vehicle manufacturing right? Just as anyone would find it ridiculous to put forward advice that could possibly apply across all of those distinctly different disciplines we should view advice about software with the same skepticism.
- cube13 15y ago
  The problem is that the industry, as a whole, is still extremely young, and simply hasn't had the time to develop a standard set of good, let alone best, practices. Tools and processes are changing at a rapid rate, and it will simply take time for best practices to sort themselves out. >"Best practices" for development of an iphone game may not be the same as for flight software for an orbital rocket or for an international banking backbone. I disagree. There are a few things that should be common across all of these, like not storing passwords in plain text.
  - bunderbunder 15y ago
    Or, for that matter, not designing programming languages such that they violate the principle of least surprise with reckless abandon.
amackera 15y ago
That example gist went a long way towards convincing me of isaacs' comma prefix style. To me, consistency is important. All of my codebase is traditional comma postfix, so I'll keep using that; however, maybe with some new projects I'll try on the comma prefix pants and see if it helps. Thanks for the link!
- jashkenas 15y ago
  To play at devil's advocate, please don't. Otherwise you should have written your comment like this: To me , consistency is important . All of my codebase is traditional comma postfix , so I'll keep using that ; however , maybe with some new projects I'll try on the comma prefix [...] ... using typography in a typographically sensible way is far more important to readability than an arbitrary "consistency" of punctation. We're humans, not computers, after all.
  - asolove 15y ago
    Why does nobody ever mention the obvious solution? Separate var statements. They're always correct, they copy without any editing, and the "var"s line up to show that it's a block of assignments the same as commas or whitespace.
    - chc 15y ago
      You can only put var at the beginning of variable declarations, but there are many other places that commas are used as a separator. So that "solution" doesn't apply in general.
      - asolove 15y ago
        I think I might have explained myself poorly. I'm suggesting using separate var statements for each assignment, e.g.: var a = 2; var b = 4; var c = { blah: "whatever" }; Leaving out a semicolon has no effect. They can be copied without any fuss. It's easy.
bentlegen 15y ago
I think using comma-first syntax as a counter example is disingenuous. Whether you're a novice programmer or an expert programmer, using comma-first or comma-last isn't going to bite you in a way that isn't immediately solvable. Omitting semi-colons, however, can cause novice JavaScript programmers serious grief. Nevermind novice JavaScript programmers – they cause me grief, and I put semi-colons everywhere! That's because I'm often called in to debug our customers websites, and on several such occasions I've had to fix bugs that never would have occurred if that customer used semi-colons properly. Sure, if our customers understood JavaScript's ASI and how to use semi-colons "properly", I wouldn't have this problem either. Except, as Tom points out, the reality is that almost none of these people will invest in doing so.
- deleted 15y ago
  [deleted]
- btilly 15y ago
  Whether you're a novice programmer or an expert programmer, using comma-first or comma-last isn't going to bite you in a way that isn't immediately solvable. Really? The comma first style makes it less likely that your list will end with a trailing comma, which can cause IE-specific bugs. If you're trying to track down the IE breakage a couple of weeks after you wrote down the code, it can be fun to track down the extra comma. If you don't know that this bug is possible (as I'm guessing you don't), multiply the hair-pulling by 10. See the cautionary story in http://www.enterprisedojo.com/2010/12/19/beware-the-trailing-comma-of-death/ http://www.enterprisedojo.com/2010/12/19/beware-the-trailing... for a real life example. With the comma first style, that bug would never have been introduced. Neat, huh?
  - aec 15y ago
    You also gain a new possible bug--the leading comma.
    - btilly 15y ago
      I have found that this is much less likely in practice. Lists usually grow on the end, not the beginning. (I use this kind of formatting for SQL, for a similar reason.)
adamesque 15y ago
The root problem is that we still don't know how to disagree when two sides look at the same set of data and believe two different things. We allow ourselves to descend into tribalism and assume the worst of each other. If you look at the language Tom objects to the most, it's language Isaac uses that promotes this tribal attitude that the other side doesn't have your best interests at heart, and questions their motives. We're just terrible at this, and I'm not sure any human society has ever really cracked it.
- chefsurfing 15y ago
  Didn't the Greeks crack it with the Trivium? http://www.triviumeducation.com/ http://www.triviumeducation.com/
- freshhawk 15y ago
  I completely disagree. We absolutely know how to resolve these kinds of disputes and it's very accurate (not as accurate as Science, but better than everything else). See my other comment here (http://news.ycombinator.com/item?id=3922527 http://news.ycombinator.com/item?id=3922527). The tribal attitude is the enemy of this process for sure, and humans are very prone to that attitude but that doesn't mean you can't still find the answer more likely to be right.
mcguire 15y ago
Who gets to play the role of expert? Presumably the "leaders in this language community" who "have given [everyone] lies and fear", according to Isaac's referenced blog post. In the absence of a true quantitative engineering method, there is a middle ground other than personal choice: common anecdotes. Presumably, those shameful leaders have heard enough stories about the issue to make a reasonable recommendation, sort of like advising against shipping server software with an open default security strategy even though I don't have any peer-reviewed studies saying such is unwise.
deleted 15y ago
[deleted]
phillmv 15y ago
I find this amusing. Stylistically, I side with the no semicolon people. Grammatically they're redundant. Pragmatically, if you ever find yourself saying "read this enormous, hard to read spec just so you can identify the three or four edge cases that will burn (yet remain statistically likely to commit)" you are on the losing side of history. Basically, it's preposterous to have reasonably smart people seriously argue that the option that is least user friendly and most likely to cause pain down the road is the best one out of a sense of misguided spec puritanism.
keyist 15y ago
"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert?" You're framing this as a disagreement between equals. It is not. There are degrees of expertise. (Total lines of production code * amount of usage) is a reasonable approximation, and those who rank highest on this scale are overwhelmingly in favor of requiring semicolons. If Carmack and Torvalds were in agreement on a C best practice while Odesker^W^W^W^W^W^W^W Topcoder user #12571 said to do something else, I wouldn't go with the latter. Google, responsible for a JS engine, multiple compilers that target JS, and what is likely to be the single largest JS codebase of any company: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Semicolons http://google-styleguide.googlecode.com/svn/trunk/javascript... Brendan Eich: "The moral of this story: ASI is (formally speaking) a syntactic error correction procedure." Or you can go with the Node.js guys.
- Darmani 15y ago
  You can think about the effect of coding style instead of letting the experts think for you. If you are doing a Topcoder round, then the random Topcoder user's advice is probably better than Carmack's. Carmack or Torvalds would probably tell you to use a variable name that gives a lot of information about its purpose, so that other people will find it easier to read your code. The Topcoder user might tell you to use a cryptic abbreviation that helps you remember a variable's purpose but clues little to the outside reader, since Topcoder users are penalized for allowing others to find their bugs. When implementing an algorithm, Carmack or Torvalds would code it as part of an extensible system with an API so that it can be used for many purposes. The Topcoder user might code it with no potential for reuse, but would do it in the way easiest to code quickly without making a mistake.
  - freshhawk 15y ago
    "You can think about the effect of coding style instead of letting the experts think for you." Right, because what could those experts possibly have to teach you? Fuck that intellectual crap, brogrammers are here to crank out some code yo! Just because those dinosaurs have spent "thousands of hours" studying and trying out different programming styles and concepts means I should listen to them? This is the internet age man. Some guy in a github comment told me different and github is cool. It's like those functional programming professors who try and talk about how continuation passing style was a bad road to go down because of maintenance problems and how difficult refactoring and just reasoning about code becomes in large systems. Fuck that egghead noise, node.js has callbacks and node is how you get webscale. I'm right with you bro!
freshhawk 15y ago
"In the absence of a quantitative engineering method with which to evaluate either approach, isn't it a purely personal and political choice?" No. Here's one idea: perhaps everyone's opinion is not equal on every subject. Perhaps by looking at the opinions of respected accomplished people who have garnered the respect of other respected accomplished people you can being to see who's opinion should get more weight. This is the process that came up with the very ideas of things like "engineering" and "quantitative". I know we love the young upstarts disrupt the old way of thinking meme. That's why you framed it this in that way with the folks vs the traditionalists. You might want to remember that historically the young upstarts have been wrong 99% of the time. That's why it's news when they are right. "One man's best practice is another man's anti-pattern" And in the vast majority of cases, when you ask that question about a specific problem: One of those men is wrong. Even if they're both smart. But how to tell? If a huge number of other smart and experienced people have been convinced by one of them ... well I'd go with that guy. You won't be right all the time but it's the best system we've come up with so far for things that don't conform to double blind placebo controlled studies or mathematical proofs. It literally is the best way to be right most often.
- Produce 15y ago
  >And in the vast majority of cases, when you ask that question about a specific problem: One of those men is wrong. Even if they're both smart. But how to tell? If a huge number of other smart and experienced people have been convinced by one of them ... well I'd go with that guy. You won't be right all the time but it's the best system we've come up with so far for things that don't conform to double blind placebo controlled studies or mathematical proofs. It literally is the best way to be right most often. This reminds me a lot of abstraction in software systems. For 95% of cases, the abstractions make things quicker in the end. For those 5% of edge cases which the abstractions don't cover properly, you spend inordinate amounts of time trying to get things to fit. The bigger point here is that trying to white-wash anything with a particular methodology is both the right and wrong thing to do. It's right because most of the time it will work, it's wrong because when it doesn't work, you will have a hell of a time dealing with it. The best system we have come up with so far is actually to take things on a case-by-case basis instead of trying to solve everything in one fell swoop. The problem is that one must be mindful as consistently as possible to achieve this. Most people are not capable of keeping that line of focus for an hour, let alone a day or their whole lives. Funnily enough, the solution to this is meditation, not a set of best practices or expert opinions.
Isofarro 15y ago
"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert? If Node.js is popular, does that mean that Isaac's comma-first style is "correct"? (https://gist.github.com/357981) https://gist.github.com/357981) No. Isaac doesn't define what style node.js is written in. And in an interview when he took on the lead developer role on he affirmed that he would abide by their current coding preference, which wasn't comma-first. That's Isaac in a nutshell, he works with the developers around him. You may be mistaking Node.js with npm. npm is Isaac's code, and that is comma-first I believe. It's his project, and his rules, and his call as to what coding style he wants. People who participate in his projects either accept that, or walk away. Node.js is an existing project, so the existing coding preferences are in place -- unless, I guess, there's a general consensus that the coding preferences in place are causing an issue.
- Produce 15y ago
  It's surprising that we haven't managed to create languages/editors which can break code down into atoms which can be presented however the developer working on said code likes. E.g. if a segment of code was tokenized properly and the editor could manipulate those tokens, coding style issues would become a thing of the past.
  - DougWebb 15y ago
    If you can express your style in a way a code-formatting tool can apply, then you can use checkout and commit hooks in your vcs to apply the formatting. Code in the repo gets a team-standard formatting, and code in your working copy gets your personal formatting. You just have to make sure the whole team uses the commit hook, at least. (Or in most systems you can apply that hook on your central/official repo.) The only problem with this approach is the diffs between the repo and your working copy.
    - Produce 15y ago
      Thanks for the tip, might try this out.

j_baker 15y ago

You can't solve everything with numbers, and I say this as someone who believes very strongly in data-driven decision-making. Even given perfect data as far as what practices are more effective, you still have the problem of interpreting it. This adds its own layer of purely personal and political choices. My advice? Don't work with people whose best practices are your anti-patterns. Or at least strive to work with people who agree with you on a core set of principles. Or hell, work with people who agree with you on nothing. Just don't complain when you can't work with any of them. :-) And besides that, what's wrong with "purely personal and political choice[s]"? Being that I'm the person who's writing my code, I'm allowed to make a certain number of purely personal choices. That is, as long as I take into account the political consequences of doing so. Put another way, it's ok to have personal preferences, but you have to take other peoples' feelings into account too.

InclinedPlane 15y ago

The problem here is viewing software development as some sort of monolithic phenomenon. "Software development" is a crude moniker that covers an incredibly wide variety of efforts, varying in scale, detail, and significance across a much wider range than anything else we consider to be a single discipline. "Best practices" for development of an iphone game may not be the same as for flight software for an orbital rocket or for an international banking backbone. Edit: to use an analogy, imagine if all vehicle development was treated with the same terminology. Whether you're building helicopters, spacecraft, mass produced commuter cars, RC toys, nuclear powered submarines, formula 1 race cars, or tunnel boring machines: all of it is just vehicle manufacturing right? Just as anyone would find it ridiculous to put forward advice that could possibly apply across all of those distinctly different disciplines we should view advice about software with the same skepticism.

cube13 15y ago
The problem is that the industry, as a whole, is still extremely young, and simply hasn't had the time to develop a standard set of good, let alone best, practices. Tools and processes are changing at a rapid rate, and it will simply take time for best practices to sort themselves out. >"Best practices" for development of an iphone game may not be the same as for flight software for an orbital rocket or for an international banking backbone. I disagree. There are a few things that should be common across all of these, like not storing passwords in plain text.
- bunderbunder 15y ago
  Or, for that matter, not designing programming languages such that they violate the principle of least surprise with reckless abandon.

amackera 15y ago

That example gist went a long way towards convincing me of isaacs' comma prefix style. To me, consistency is important. All of my codebase is traditional comma postfix, so I'll keep using that; however, maybe with some new projects I'll try on the comma prefix pants and see if it helps. Thanks for the link!

jashkenas 15y ago
To play at devil's advocate, please don't. Otherwise you should have written your comment like this: To me , consistency is important . All of my codebase is traditional comma postfix , so I'll keep using that ; however , maybe with some new projects I'll try on the comma prefix [...] ... using typography in a typographically sensible way is far more important to readability than an arbitrary "consistency" of punctation. We're humans, not computers, after all.
- asolove 15y ago
  Why does nobody ever mention the obvious solution? Separate var statements. They're always correct, they copy without any editing, and the "var"s line up to show that it's a block of assignments the same as commas or whitespace.
  - chc 15y ago
    You can only put var at the beginning of variable declarations, but there are many other places that commas are used as a separator. So that "solution" doesn't apply in general.
    - asolove 15y ago
      I think I might have explained myself poorly. I'm suggesting using separate var statements for each assignment, e.g.: var a = 2; var b = 4; var c = { blah: "whatever" }; Leaving out a semicolon has no effect. They can be copied without any fuss. It's easy.

bentlegen 15y ago

I think using comma-first syntax as a counter example is disingenuous. Whether you're a novice programmer or an expert programmer, using comma-first or comma-last isn't going to bite you in a way that isn't immediately solvable. Omitting semi-colons, however, can cause novice JavaScript programmers serious grief. Nevermind novice JavaScript programmers – they cause me grief, and I put semi-colons everywhere! That's because I'm often called in to debug our customers websites, and on several such occasions I've had to fix bugs that never would have occurred if that customer used semi-colons properly. Sure, if our customers understood JavaScript's ASI and how to use semi-colons "properly", I wouldn't have this problem either. Except, as Tom points out, the reality is that almost none of these people will invest in doing so.

deleted 15y ago
[deleted]
btilly 15y ago
Whether you're a novice programmer or an expert programmer, using comma-first or comma-last isn't going to bite you in a way that isn't immediately solvable. Really? The comma first style makes it less likely that your list will end with a trailing comma, which can cause IE-specific bugs. If you're trying to track down the IE breakage a couple of weeks after you wrote down the code, it can be fun to track down the extra comma. If you don't know that this bug is possible (as I'm guessing you don't), multiply the hair-pulling by 10. See the cautionary story in http://www.enterprisedojo.com/2010/12/19/beware-the-trailing-comma-of-death/ http://www.enterprisedojo.com/2010/12/19/beware-the-trailing... for a real life example. With the comma first style, that bug would never have been introduced. Neat, huh?
- aec 15y ago
  You also gain a new possible bug--the leading comma.
  - btilly 15y ago
    I have found that this is much less likely in practice. Lists usually grow on the end, not the beginning. (I use this kind of formatting for SQL, for a similar reason.)

adamesque 15y ago

The root problem is that we still don't know how to disagree when two sides look at the same set of data and believe two different things. We allow ourselves to descend into tribalism and assume the worst of each other. If you look at the language Tom objects to the most, it's language Isaac uses that promotes this tribal attitude that the other side doesn't have your best interests at heart, and questions their motives. We're just terrible at this, and I'm not sure any human society has ever really cracked it.

chefsurfing 15y ago
Didn't the Greeks crack it with the Trivium? http://www.triviumeducation.com/ http://www.triviumeducation.com/
freshhawk 15y ago
I completely disagree. We absolutely know how to resolve these kinds of disputes and it's very accurate (not as accurate as Science, but better than everything else). See my other comment here (http://news.ycombinator.com/item?id=3922527 http://news.ycombinator.com/item?id=3922527). The tribal attitude is the enemy of this process for sure, and humans are very prone to that attitude but that doesn't mean you can't still find the answer more likely to be right.

mcguire 15y ago

Who gets to play the role of expert? Presumably the "leaders in this language community" who "have given [everyone] lies and fear", according to Isaac's referenced blog post. In the absence of a true quantitative engineering method, there is a middle ground other than personal choice: common anecdotes. Presumably, those shameful leaders have heard enough stories about the issue to make a reasonable recommendation, sort of like advising against shipping server software with an open default security strategy even though I don't have any peer-reviewed studies saying such is unwise.

deleted 15y ago

[deleted]

phillmv 15y ago

I find this amusing. Stylistically, I side with the no semicolon people. Grammatically they're redundant. Pragmatically, if you ever find yourself saying "read this enormous, hard to read spec just so you can identify the three or four edge cases that will burn (yet remain statistically likely to commit)" you are on the losing side of history. Basically, it's preposterous to have reasonably smart people seriously argue that the option that is least user friendly and most likely to cause pain down the road is the best one out of a sense of misguided spec puritanism.

keyist 15y ago

"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert?" You're framing this as a disagreement between equals. It is not. There are degrees of expertise. (Total lines of production code * amount of usage) is a reasonable approximation, and those who rank highest on this scale are overwhelmingly in favor of requiring semicolons. If Carmack and Torvalds were in agreement on a C best practice while Odesker^W^W^W^W^W^W^W Topcoder user #12571 said to do something else, I wouldn't go with the latter. Google, responsible for a JS engine, multiple compilers that target JS, and what is likely to be the single largest JS codebase of any company: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Semicolons http://google-styleguide.googlecode.com/svn/trunk/javascript... Brendan Eich: "The moral of this story: ASI is (formally speaking) a syntactic error correction procedure." Or you can go with the Node.js guys.

Darmani 15y ago
You can think about the effect of coding style instead of letting the experts think for you. If you are doing a Topcoder round, then the random Topcoder user's advice is probably better than Carmack's. Carmack or Torvalds would probably tell you to use a variable name that gives a lot of information about its purpose, so that other people will find it easier to read your code. The Topcoder user might tell you to use a cryptic abbreviation that helps you remember a variable's purpose but clues little to the outside reader, since Topcoder users are penalized for allowing others to find their bugs. When implementing an algorithm, Carmack or Torvalds would code it as part of an extensible system with an API so that it can be used for many purposes. The Topcoder user might code it with no potential for reuse, but would do it in the way easiest to code quickly without making a mistake.
- freshhawk 15y ago
  "You can think about the effect of coding style instead of letting the experts think for you." Right, because what could those experts possibly have to teach you? Fuck that intellectual crap, brogrammers are here to crank out some code yo! Just because those dinosaurs have spent "thousands of hours" studying and trying out different programming styles and concepts means I should listen to them? This is the internet age man. Some guy in a github comment told me different and github is cool. It's like those functional programming professors who try and talk about how continuation passing style was a bad road to go down because of maintenance problems and how difficult refactoring and just reasoning about code becomes in large systems. Fuck that egghead noise, node.js has callbacks and node is how you get webscale. I'm right with you bro!

freshhawk 15y ago

"In the absence of a quantitative engineering method with which to evaluate either approach, isn't it a purely personal and political choice?" No. Here's one idea: perhaps everyone's opinion is not equal on every subject. Perhaps by looking at the opinions of respected accomplished people who have garnered the respect of other respected accomplished people you can being to see who's opinion should get more weight. This is the process that came up with the very ideas of things like "engineering" and "quantitative". I know we love the young upstarts disrupt the old way of thinking meme. That's why you framed it this in that way with the folks vs the traditionalists. You might want to remember that historically the young upstarts have been wrong 99% of the time. That's why it's news when they are right. "One man's best practice is another man's anti-pattern" And in the vast majority of cases, when you ask that question about a specific problem: One of those men is wrong. Even if they're both smart. But how to tell? If a huge number of other smart and experienced people have been convinced by one of them ... well I'd go with that guy. You won't be right all the time but it's the best system we've come up with so far for things that don't conform to double blind placebo controlled studies or mathematical proofs. It literally is the best way to be right most often.

Produce 15y ago
>And in the vast majority of cases, when you ask that question about a specific problem: One of those men is wrong. Even if they're both smart. But how to tell? If a huge number of other smart and experienced people have been convinced by one of them ... well I'd go with that guy. You won't be right all the time but it's the best system we've come up with so far for things that don't conform to double blind placebo controlled studies or mathematical proofs. It literally is the best way to be right most often. This reminds me a lot of abstraction in software systems. For 95% of cases, the abstractions make things quicker in the end. For those 5% of edge cases which the abstractions don't cover properly, you spend inordinate amounts of time trying to get things to fit. The bigger point here is that trying to white-wash anything with a particular methodology is both the right and wrong thing to do. It's right because most of the time it will work, it's wrong because when it doesn't work, you will have a hell of a time dealing with it. The best system we have come up with so far is actually to take things on a case-by-case basis instead of trying to solve everything in one fell swoop. The problem is that one must be mindful as consistently as possible to achieve this. Most people are not capable of keeping that line of focus for an hour, let alone a day or their whole lives. Funnily enough, the solution to this is meditation, not a set of best practices or expert opinions.

Isofarro 15y ago

"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert? If Node.js is popular, does that mean that Isaac's comma-first style is "correct"? (https://gist.github.com/357981) https://gist.github.com/357981) No. Isaac doesn't define what style node.js is written in. And in an interview when he took on the lead developer role on he affirmed that he would abide by their current coding preference, which wasn't comma-first. That's Isaac in a nutshell, he works with the developers around him. You may be mistaking Node.js with npm. npm is Isaac's code, and that is comma-first I believe. It's his project, and his rules, and his call as to what coding style he wants. People who participate in his projects either accept that, or walk away. Node.js is an existing project, so the existing coding preferences are in place -- unless, I guess, there's a general consensus that the coding preferences in place are causing an issue.

Produce 15y ago
It's surprising that we haven't managed to create languages/editors which can break code down into atoms which can be presented however the developer working on said code likes. E.g. if a segment of code was tokenized properly and the editor could manipulate those tokens, coding style issues would become a thing of the past.
- DougWebb 15y ago
  If you can express your style in a way a code-formatting tool can apply, then you can use checkout and commit hooks in your vcs to apply the formatting. Code in the repo gets a team-standard formatting, and code in your working copy gets your personal formatting. You just have to make sure the whole team uses the commit hook, at least. (Or in most systems you can apply that hook on your central/official repo.) The only problem with this approach is the diffs between the repo and your working copy.
  - Produce 15y ago
    Thanks for the tip, might try this out.