Maintaining Maximum Line Length When Using Tabs In

问题:

Style guides for various languages recommend a maximum line length range of 80–100 characters for readability and comprehension.

My question is, how do people using tabs for indentation comply with the line length limits? Because, if the length of a tab is set to 2 in your editor, the same code could be over 80 characters long in someone else's editor with tab length set to 3/4/6/8.

Some suggest that I mentally see my tab length at 8 characters. This isn't realistic and won't let me focus on programming as I'd have to check it for every other line.

So, how do you (if you use only tabs in your code) do it?

回答1:

Almost all languages have a convention for tab size. Most projects have a convention for tabs size as well, which is usually (though not always) the same as the language's tab size.
For example, Ruby is 2, Python & PHP is 4, C is 8, etc.

Sticking with the project's tab length, or the language tab size if there is no obvious project tab size, is by far the most sane thing to do, since this what almost all people will use, except perhaps a few.
The ability to set a different tab size is probably the largest advantage of using tabs instead of spaces, and if a user wants to deviate from the standard, then that's fine, but there is no reasonable way to also comply with the maximum line length in every possible situation.

You can compare it to most web sites; they're designed for a 100% zoom level. Zooming in or changing the font size almost always works, but some minor things may break. It's practically impossible to design for every possible zoom level & font size, so artefacts are accepted.

If you want to make sure the code complies to both the line length and tab size, you should probably use spaces, and not "real" tabs. Personally, I feel these guidelines are exactly that: guidelines; and not strict rules, so I don't think it matters that much. Other people's opinion differs on this matter, though.

Personally, I like tabs, for a number of reasons which are not important now, but only deviate from the standard temporarily, usually when editing heavy-nested code where I would like some more clarity which block I'm editing.

回答2:

You probably don't write very long lines often, so you probably won't have to reformat your code too often.

Therefore, you can use an approach where you periodically check your file for compliance, and fix anything that's out of whack (for example, you could do this before submitting the file to code-review).

Here's a trivially simple Python script that takes a file on stdin and tells you which lines exceed 80 chars:

TABSIZE = 8
MAXLENGTH = 80
for i, line in enumerate(sys.stdin):
    if len(line.rstrip('\n').replace('\t', ' '*TABSIZE)) > MAXLENGTH:
        print "%d: line exceeds %d characters" % (i+1, MAXLENGTH)

You can extend this in various ways: have it take a filename/directory and automatically scan everything in it, make the tab size or length configurable, etc.

回答3:

Some editors can be set up to insert a number of spaces equal to your tab length instead of an actual tab (Visual Studio has this enabled by default). This allows you to use the tab key to indent while writing code, but also guarantees that the code will look the same when someone else reads it, regardless of what their tab length may be.

Things get a little trickier if the reader also needs to edit the code, as is the case in pretty much every development team. Teams will usually have tabs vs. spaces and tab length as part of their coding standard. Each developer is responsible for making their own commits align with the standard, generally by setting up their environment to do this automatically. Changes that don't meet the standard can be reverted, and the developer made to fix them before they get integrated.

回答4:

If you are going to have style guidelines that everyone has to follow then one way to insure that all code conforms to a column width maximum of 100 is to use code formatter such as Clang Format on check-in for example they include a option to set the ColumnLimit:

The column limit.

A column limit of 0 means that there is no column limit. In this case, clang-format will respect the input’s line breaking decisions within statements unless they contradict other rules.

Once your team agrees to the settings then no one has to think about these details on check-in code formatting will be automatically done. This requires a degree of compromise but once in place you stop thinking about pretty quickly and you just worry about your code rather then formatting.

回答5:

If you want to ensure you don't go over the limit as prescribed in a team/project coding standard, then it would be irrational to not also have a teamp/project standard for tab width. Modern editors let you set the tab width, so if your team decides and everyone sets their editor to that tab width, everyone will be on the same page.

Think if a line is 100 characters long for you and someone comes by and says it's over because their editor is set to 8 while yours is 2. You could tell them they have the wrong tab width and be making just as valid a point as they could if they told you your tab width was wrong if there's no agreed upon standard. If there's not, the 8-width guy will be wrong when he writes a 100 character line and another developer who prefers 10-width tabs complains.

Where tabs don't inherently have a defined width, it's up to the team to either choose one or choose not to engage in irrational arguments about it.

That said, spaces are shown to be correlated with higher income, so, y'know... ;)