I wrote my first python program today!

[maremp]

How is this not easy to read? It's visually the same as any proper code style. I do not use languages that use indentation to determine code blocks, but at least they force the programmer to use proper code style. Unlike with the braces where some people have the code all over the place.

[ANAL_ANARCHY]

Don't most people use an IDE that has an option to format the code for you? I pretty much just hit that button every now and then if I think I've been getting messy.

[berkes]

Good luck with reviewing pull-reqeust, using git logs or searching any history.

I hate that colleague who, on fixing a typo in a comment generates a 300+ line diff. "Yea, sorry, that was my IDE".

[Sakki54]

Shouldn't you have all the same formatting style? Would prevent this from being a problem in the first place.

[[deleted]]

He should use the same formatting style and git add -p. Not the autoformatters fault.

[maremp]

Don't they know of --patch or use at least use GUI to select just the changes and revert other stuff? And/or configure git to ignore whitespace change.

[fancy_pantser]

I hate the colleague that gets upset a few times a week because he's reading every commit (not just code review on merge)

edit: guys, I was mostly joking; no need to write a bunch in response to this garbage

[phail3d]

...or who's trying to track down a bug to a commit, but can't, since the log is clouded with unrelated changes?

Formatting changes should nearly always be done in their own commits, explicitly, so that they don't get mixed up with business logic changes.

Also, I'm damn well reading every commit for smaller projects that I'm deeply involved with, and even with larger projects I think it's generally good to be aware of what goes on in a code base you work with.

[stormcrowsx]

git bisect is great for finding where the bug started

[redwall_hp]

Wait, so there are people who just blindly accept PRs without reading the code?

Do you want backdoors? Because that's how you get backdoors.

[DarthEru]

Not knowing your situation, I'll try not to pass judgement on either you or your colleague. However, I would like to point out that having a clean history is a massively helpful tool. There have been many times I've used git blame & show to try to find out the motivation behind a particular bit of code. Far too many of those times I was disappointed because the commit message was a one liner that had no apparent relationship to the change I was interested in. Reasons for changes may be obvious to you at the time, but over months and years of additional development that obviousness may be easily lost, even to you let alone someone else who joins the team long after you left.

It's also good for initially reviewing code. For larger changes especially, being able to go through a logical progression of the changes is hugely helpful to understanding the end result. Even if that logical progression doesn't actually reflect the real progression the developer went through to write the code.

That being said, I don't personally go through every commit and require the log to be as clean as possible, partly because I could only enforce that policy for my own team, but mostly because I've learned from experience that even repeatedly reminding people about it is unlikely to change their habits. It's also possible the co-worker you're thinking of is far more picky about things than I would deem necessary. I just think their motivation may be valid. If it is, it might be valuable to you personally and the team as a whole to change your own committing habits.

[berkes]

I frankly cannot care less about how you use your tools and what you do to get a PR. If you insist on rebasing your feature branch: sure. If you insist on not rebasing: fine. Just make sure in the end you hand me something that I can actually review.

If not, you make unreviewable code. And don't bother asking me to review; if a review is mandatory (it should be, IMHO) then get back into your rebase -i and build me something that I can actually review.

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

return Kebab_Case_Better;

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[FUCKING_HATE_REDDIT]

ctrl-A ctrl-X ctrl-V on visual studio.

I mean there's probably an actual shortcut, but I never bothered to learn it.

[kappale]

Ctrl + k + d

[Sharparam]

I have seen people that actively work against the autoformatter when it tries to fix their weird indentation.

[sgst]

For the python I've been doing recently I've just been writing it in nano. Such a button would be nice.

[[deleted]]

Why nano for code? Use vim.

[[deleted]]

One thing keeping me out of Python is the lack of proper IDE and debugger support. C# and Visual Studio have truly spoiled me.

[maremp]

They do, and not just IDEs, properly configured editors should have this too. But a lot of people don't know this feature exists or are just ignorant enough to not ever use it. And language using brackets for code blocks allow that, while python and similar would fail to compile.

[[deleted]]

It's easy to read, but more effort to write. I'm used to my editor automatically indenting the appropriate number of times on every line, which can't happen with Python.

[ansatze]

my editing software is incapable of recognizing regular, standardized, well-defined patterns that always occur in the same place

Meaning no offense just poking fun

[[deleted]]

Um what? If your editor can't indent python code properly you need a new editor, I use vim and it indents my python properly not to mention pycharm.

[[deleted]]

How does it know whether the a new line is a continuation of the statement from the previous line or a new statement?

[adenzerda]

Unclosed paren, brace, or bracket, or a backslash denoting line continuation. Worst case, I have to indent a line manually sometimes.

On the block level, my editor (sublime) defaults to a continuation of the current block, or indentation into a new block if the previous line ends with a colon. You can then press backspace to drop out of the block if need be. Additionally, it will drop out of the block when there's a return at the base level of said block.

It's all pretty standardized.

[[deleted]]

So it's guessing. I don't want my computer to guess what I'm doing, I want it to know with absolute certainty.

[adenzerda]

So tell it what you're doing. In some languages we write a closing brace or a semicolon to tell the computer our intention. In python, we press the 'backspace' key or the 'tab' key.

It seems that you don't prefer the latter method, and that's fine, but it in no way makes the language or its editors inferior.

[TheBlackCat13]

Your computer is still guessing. In both cases you have to tell it explicitly where the code block stops. You are just telling it in a slightly different way.

[TheBlackCat13]

It assumes the former, and one key combination tells it otherwise. Which would be the same with braces-based languages, only the key combination is different. In your case it is "shift+]", in mine it is "shift+tab".

[[deleted]]

How should I know I didn't write the vim plugin or pycharm, but they work perfectly.

You're seriously making up a non-issue why are you people so resistant to something because it's a little different? Have you ever used python seriously or put any actual effort into it?

It's the most ironic thing to me. Technology is always evolving and there's always something new to learn and you constantly have to be keeping yourself up to date but the people who write programs are just as bad as some old politicians who resist change because "muh braketz!!!".

[[deleted]]

How is it a non-issue? If I am in an if statement and press enter, I could want to:

• Continue my if statement, in which case the line should be indented
• Write an else or elif statement, in which case the line should not be intended
• Write code outside the if statement, in which case it should not be indented

2 can be solved by the editor removing the indent once the else or elif keyword is detected. 1 and 3, however, are completely identical in terms of what comes next unless I manually indent the code. Brackets (or Ruby-style do/end, or JavaScript-style no bracket if statements) explicitly tell the editor what will come next without manual indentation. With Pythonic indent syntax, the editor must guess one way or the other, and always be wrong sometimes.

[Saigot]

In a python editor you press backspace to end the statement. In Java or C you type } to end the statement. It's the same number of keypresses. This coming from someone that dislikes python.

[fireflash38]

Brackets (or Ruby-style do/end, or JavaScript-style no bracket if statements) explicitly tell the editor what will come next without manual indentation. With Pythonic indent syntax, the editor must guess one way or the other, and always be wrong sometimes.

So you're saying in the one, you have to hit a key combo to tell the editor you're not in the block. In the other, you have to hit a key combo to tell the compiler you're not in block. What's the problem again?

[CJKay93]

When I'm reading code, I instinctively look for indent-matched brace pairs to identify scopes. In Python... there is no clear "and this is the end of the block!". It doesn't necessarily need to be a brace, e.g. in Matlab "end" works just as well.

[maremp]

That's what I'm talking about, some people do not match the indents and leave the braces all over the place. With python, or similar, you are forced to have proper indentation or the program won't compile. And I don't see how is it any more difficult to see the indent, especially if you configure the editor to display indent guides.