4 ms·

The benefit of using tabs with a tab width of 8, and limiting screen with to 80 columns (like old text based terminal) is that you limit how many loops and cond

The benefit of using tabs with a tab width of 8, and limiting screen with to 80 columns (like old text based terminal) is that you limit how many loops and conditions you can nest in a single function due to running out of horizontal space. Eg, it encourages you to break functions with complex nested loops/conditionals into smaller functions. EDIT: Both the Linux and BSD kernel coding style specify tabs for indentation, and a tab width of 8. The Linux guide says it best: "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning."

rollcat 3y ago
> Eg, it encourages you to break functions with complex nested loops/conditionals into smaller functions. Did you read the Emacs source much? They compensate by having functions span thousands of lines
- deleted 3y ago
  [deleted]
bsder 3y ago
> "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning." And, yet, that becomes so much religious dogma that people will shoot themselves in the foot. I fixed a lot of network locking code way back when. I made sure that I had a validation framework to go along with it. It was a gigantic state machine, because that's what locking and protocol are. But, you know, that thing had single exit point and 4-5 indent levels and extended past 80 characters because it was a goddamn state machine, had states and variables lifted directly from the specification state machine, and tested as a state machine with the validation suite. But, hey, the kernel devs just had to rewrite it to match 2 indents and 80 character lines. So, they did. And took 9 months until they passed the validation suite again. They didn't add a single feature. They didn't fix a single bug. But, hey, they dedented it real good. What finally did the deed was that one of the senior devs finally got fed up, went back to my original code, wrote a Perl script (that's how regular my code was) to rewrite every state block into a function with extremely short, unintelligibly cryptic names and args in order to remove two levels of indent and make sure the function calls would fit in 80 characters. The final kicker: someone genuinely found a real bug about 5 weeks afterward. They tried to fix it in the "better" code with less indents. They couldn't figure out which state was the problem because they mangled all the names. I went into my old code, fixed it, added a test to the suite and reran the refactoring script--and that's how the bug got fixed. We're not developing on punch cards and VT100s anymore people--quit being stupid. (Side note: the main issue that bit the devs is that people who are dogmatic about 2 tabs-80 characters tend to rely on early return to avoid fully-fleshed if-then-else which cause deeper chains. This does not work for state machines. There is no early return--every state should leave at exactly the point when you advance from the old state to the new state at the atomic swap. So, you can do what the senior dev did and cryptify everything, or you can just leave the damn state machine alone and accept 4 indents and 132 characters.)

rollcat 3y ago

> Eg, it encourages you to break functions with complex nested loops/conditionals into smaller functions. Did you read the Emacs source much? They compensate by having functions span thousands of lines

deleted 3y ago
[deleted]

bsder 3y ago

> "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning." And, yet, that becomes so much religious dogma that people will shoot themselves in the foot. I fixed a lot of network locking code way back when. I made sure that I had a validation framework to go along with it. It was a gigantic state machine, because that's what locking and protocol are. But, you know, that thing had single exit point and 4-5 indent levels and extended past 80 characters because it was a goddamn state machine, had states and variables lifted directly from the specification state machine, and tested as a state machine with the validation suite. But, hey, the kernel devs just had to rewrite it to match 2 indents and 80 character lines. So, they did. And took 9 months until they passed the validation suite again. They didn't add a single feature. They didn't fix a single bug. But, hey, they dedented it real good. What finally did the deed was that one of the senior devs finally got fed up, went back to my original code, wrote a Perl script (that's how regular my code was) to rewrite every state block into a function with extremely short, unintelligibly cryptic names and args in order to remove two levels of indent and make sure the function calls would fit in 80 characters. The final kicker: someone genuinely found a real bug about 5 weeks afterward. They tried to fix it in the "better" code with less indents. They couldn't figure out which state was the problem because they mangled all the names. I went into my old code, fixed it, added a test to the suite and reran the refactoring script--and that's how the bug got fixed. We're not developing on punch cards and VT100s anymore people--quit being stupid. (Side note: the main issue that bit the devs is that people who are dogmatic about 2 tabs-80 characters tend to rely on early return to avoid fully-fleshed if-then-else which cause deeper chains. This does not work for state machines. There is no early return--every state should leave at exactly the point when you advance from the old state to the new state at the atomic swap. So, you can do what the senior dev did and cryptify everything, or you can just leave the damn state machine alone and accept 4 indents and 132 characters.)