Effective PyCharm Transcripts
Chapter: The Editor
Lecture: Code formatting for teams
Login or
purchase this course
to watch this video and the rest of the course contents.
0:01
The code formatting fixes that we saw before, those were actually based on the coding style that we told PyCharm to follow,
0:09
and chances are they were the default, but not everybody follows the default, and normally that's not really a big thing
0:16
unless you're working in a team and you have version control and you both reformat a file, what are you going to get— you're going to at best get
0:26
this file is changed, this line is changed, it was indented, this line is changed, it was unintended,
0:31
this line is changed, it was indented, back and forth like the fighting every time somebody reformats a file,
0:36
every difference in that formatting style is going to surface and show up as a difference.
0:41
And in a worst-case scenario, these are going to be merge conflicts. This can be a super pain in the rear if you are working in a team.
0:50
Luckily there is a fix for that, so if we go to preferences, go to code style and we'll just focus on PyCharm but notice
0:57
we could do this for Haml or Javascript or whatever. Notice across the top, there are 6 tabs up there and each tab has a ton of options
1:08
like for method call arguments, where do you align them if it's multi-line and so on. You can go through and you can configure all of these
1:16
or you could import or export a file, so this is really cool so you could basically configure everyone on the team say,
1:23
this is the style we're going to use, you configure it here, export it, everyone imports it. However, that's great, if you are on a single team
1:30
like say work machine and we're only writing code against our one project; what if you are multiple teams, with different styles,
1:37
what if you're contributing to an open source project that has one style and you're also working on your project at work
1:43
which is a different style like that's a super pain, right. You can also fix that. Over here, you can say you can set up some styles
1:53
and copy it to a project or export it to a file, so I could export this to a file and share with my team
2:00
and give it a name and you could pick the style and things like that that's really great. You can also say for this particular project
2:08
store the formatting settings in source control, so there'll be a hidden .idea folder with a few files that talk about the project,
2:16
and one of those can describe things like what is the formatting style around method arguments
2:23
so you can actually store the settings for the format inside the project so you open up different projects, run CMD alt L, reformat the file
2:31
that might mean different things based on that particular projects style choices so here's a couple of things you can do
2:38
in terms of helping team members end up on the same style page because as I outlined in the beginning,
2:46
if you don't that makes version control a real pain.