If there was a command line switch, would you use it? Why?
It's also fun to spend an hour looking for a bug caused by somebody inserting a tab instead of a space somewhere. We had a production crash that took us a long time to fix because somebody hotfixed a file with the wrong editor and did this.
I also don't understand how forcing people to indent code in the same way magically makes people write good code. The kind of programmer that can't or won't indent his code properly is introducing bugs far more serious than bad layout into your project.
Python's a nice language in many ways but I consider the syntax to be a bug.
# if x:
if 1: # DEBUG
block if 1: # x:
blockThis. I'm convinced half the reason Ruby is displacing Python is that it's actually practical to talk about Ruby code in forums without ridiculous little-known workarounds like pastebins.
The Ruby community itself does strike me as more energetic though. All the activity on github etc seems a lot more impassioned to me than the coolheaded & practical world of Django et al.
Hotfixing is a naturally perilous process regardless of language. I've spent hours tracking down untested hotfixes in Java.
You're also probably less likely to come across a badly formatted block of python code because that would generally result in a bug. Much like misplaced brackets in Java/C/C++ would result in a bug.
It doesn't make the code magically better. It makes it less redundant. Indentation should already be there, why do you need curly brackets?
Copying and pasting is also known as refactoring. A syntax that makes that much harder than it needs to be is mis-optimized, IMO.
To my knowledge, this is no worse than the expectation for a braced language, but much better than the worst case for a braced language.
If you mean something simpler than I've taken you to mean, e.g., the conversion of a whitespaceless C program into a whitespaced one, I concede you are mostly correct (';' still works in Python), but I must admit I would still not yet see your point.
if x:
# do stuff
# do other stuff
Your indenter will not know where to put the third line.In languages whose blocks are closed using nonwhitespace the problem doesn't exist. Your indenter just has to push everything as far to the right as it can, and problem solved.
It's nice that your editor gets copy and paste right, but it doesn't and indeed can't decide how to indent your code, something that works in every other language I've dealt with.
In brace language:
if (condition) {{ code_1 }} code_2
In Python:
if (condition):\n code_1 \n^H code_2
Unless your editor also knows when to place your close braces, and, haha, it doesn't and indeed can't, you have not even won a keystroke.
It's got nothing about saving keystrokes.
And now, back to working on pass-infested Python code.
This kind of "automatic indentation" (colon-enter to indent, a quick backspace to unindent) feels much more natural to me than a C-style indent, where the editor's cue to indent would be space-rightbracket-enter and leftbracket-enter to unindent.
True, one cannot come accross a completely unindented block of python code and ask the editor to format it correctly for them. But by definition, unindented code is not valid python and will not run. This is not unlike C / C++ / Java code that's missing all its braces, which would not run either.
The pain of keeping indentation correct is a forced ongoing investment in readability that is well worth it--at least to me.
I'm glad that haskell also has whitespace rules.
Technically, your editor should take care of that for you, but some of them don't do it properly (and sometimes can't do it properly), and it really sucks.
Well, everything has a downside :)
Do any exist for Python or Perl?
1. People don't indent consistently. There are a lot of (imo, pointless) arguments about where to place the braces, etc. One of the advantages of the language forcing a style is that arguments about it are no longer necessary.
2. Why should tools be taking care of this? People indent to understand the code better. Everyone agrees that you have to do it. So what's the problem with the language forcing you to do it? I'd rather it be part of the language than an external tool enforcing it.
But in Python, you don't even have to worry about other people not indenting their code!
I guess the only complaint I might have is why bother thinking about indentation, ever? Throw in a couple of {} and now the tools can provide additional help.
When you edit Python, the tools can already help as much. The start of a block is obvious (def, if, for, etc), so tools indent for you. To dedent, just hit the right key (e.g. a backspace on an empty line in emacs) -- no harder than hitting the brace key.
I don't like Python either and prefer Perl. (In Python I did not like indentations, dicts, tuples, lists, and the IDLE gui.)
And to the parent: I really hate to be "that guy", but can you give me an example where non-indented code looks better than indented code (since all your complaint really is about is style rather than what Python can help you do)? If it's just braces you're after, Python "supports" those by just commenting them out. When I first learned Python years back I was coming from a PHP and some Java background, and my code was sometimes single-space-indented, sometimes not indented at all, and it was hideous. After I realized I should be indenting anyway, Python made a lot of sense, all these languages with braces or 'end's everywhere didn't, and I can't think of any case I've ever thought "Man, I wish I didn't have to indent here." The one thing I can say I don't exactly like about Python now is the occasional self-hell.
Of course, most situations can be solved by a backslash-enter, and simple statements can be separated by ; but there are places where I wished for more flexibility.
This is only about readability, and overall Python code tends to be more readable than in other languages, although I've read beautifully written code in Java or Perl or C++, and the readability really depends a lot on the programmer writing it.
I think the major problem is the lack of focus in high-school / college on such things ... quite the contrary, many teachers are usually disconnected from real-world projects and don't have this skill themselves.
http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...
In fact at Google the maximum line length for python code is 80 characters because long lines make the code unreadable, and following the style guide basically anything can fit in a nice and readable way.
The only time I've had a problem with indentation is while copy-pasting things, occasionally that can get messed up and be annoying. Everything else is fine.
There are some interesting ideas regarding the use of whitespace in C here:
http://www.quinapalus.com/coding.html
I don't agree with everything he has to say- for example, I think his nested for loop example would be far nicer as something like this:
for(i=0;i<10;i++) {
for(j=0;j<10;j++) {
for(k=0;k<10;k++) {
printf("%d %d %d\n",i,j,k);
}
}
}
(Not to mention more in keeping with the principle of "alignment".) Still, if nonstandard indentation can make it easier to see the patterns in your code, it benefits both development and maintenance.for (i = 0; i < 1000; i++)
printf ("%d %d %d\n", i / 100, (i % 100) / 10, i % 10);
IMHO, such patterns (multiple nesting with empty outer loops), in most cases, are really an indication of just one real loop. Using multiple counters might also be an option.In case the loops are doing something different, they should be indented separately. For instance, the following makes little sense:
for (i = 0; i < 10; i++) {
foo (i);
for (j = 0; j < 10; j++) {
foo (i + j);
for (k = 0; k < 10; k++) {foo (i + j + k);
}
}
}
Let's say I'm making a simple tile-based game that uses a two-dimensional array called "grid" to store the map. To draw that map to the screen, I might do something like the following:
for(int x = 0; x < grid.length; x++) {
for(int y = 0; y < grid[0].length; y++) {
drawTile(grid[x][y], x * tileWidth, y * tileHeight);
}
}
There are other ways to refashion this as a single loop, (storing everything in a 1d array and handling the dimensioning ourselves, using an iterator and giving tiles a position attribute containing their (x,y) coordinates, etc) but is any of that really more straightforward?Again, I am not arguing for indentation anarchy, merely that there are times when it can help to bend the rules.
edit: I imagine you'd prefer something like this?
for(int t = 0; t < grid.length * grid[0].length; t++) {
int x = t % grid.length;
int y = t / grid.length;
drawTile(grid[x][y], x * tileWidth, y * tileHeight);
}Of course I prefer Ruby, but that's a whole other can of worms :)
I'm not against the non-Perl philosophy of There Is Only One Way To Do It, but for God's sake, don't insist on indentation! I am under a personal vow that until Python lifts its indentation requirement (say, via a command-line switch), I'm no way using this language for my programming needs.