Significant indentation

Ray Dillinger wrote:


>>For example, you can get away without semicolons for statement
>>separators if you use indentation and/or distinctive keywords.
>
> I still think significant indentation is annoying. When code gets
> moved from point A to point B, it frequently changes indentation
> level.


That's a Python-specific problem. It's a bad idea to equate a tab
character with 8 spaces.
Also, the issues are made worse by braindead editors that try to
compress source code by replacing 8 spaces with one tab, without
recognizing that there are editors out there that display a tab as 3
spaces. Or 5 spaces. Or whatever the user had set of the indentation
level. The worst source code that I had to work with had indentation
levels of 3 spaces, and the editor had done that 8-spaces-for-one-tab
replacement - I had my indentation level set to 2 and didn't see much of
a structure anymore :-(


Fortunately, most editors with braindead tab handling can be configured
to work differently. It's a problem with tools, not a problem with the
concept per se.


  > Significant indentation means I can't just let my editor
  > autoindent it for me.


If the editor automatically replicates the leading space of the previous
line for new lines, you have all the autoindentation support you'd ever
need:
Instead of tying an opening a brace, you type an additional single tab
in the first line of the block; instead of typing a closing brace, you
backspace over the last of those automatically-provided tabs.
Instead of removing a pair of braces, you unindent a block, adding a
pair of braces is equivalent to indenting.
  From the perspective of source code manipulation, I don't see much of a
difference - it's roughly the same number of keypresses. From the
perspective of source code inspection, it's a clear win: less syntactic
clutter on the screen (and less holy wars on the "proper indentation
style" as a fringe benefit).


Regards,
Jo

Return to the comp.compilers page.
Search the comp.compilers archives again.