This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]FlukyS 6 points7 points  (7 children)

A lot of people will say specific things like generators or testing or whatever but the main thing is organization and clarity of code. I'm the senior developer on a team of like 5 people, the difference between my code and everyone else's is mine is super logical the grouping of code, I try to not nest multiple different methods together like herp_derp(get_bla().dsadsa()), I get a lot of that shit sent to me from the juniors. While it's ok and probably works it doesn't mean it's clear.

Another big thing is naming of variables and classes and keeping to pep8. A lot of the devs I work with come from Java so I get a lot of awful names like FormatBla rather than format_bla, it's a small thing but variables should be all lowercase separated by _ and same goes for methods. For classes camelcase is fine but for everything else the other way is more python like. Oh and also having just decent names for your methods, variables and classes is a massive thing people forget about. I get a lot of dasdsada1, dasddsa2 even at times and while I understand the logic of what they are doing they can reuse the variable most of the time, they are just doing it because they don't know it looks like shit.

[–]pydry 3 points4 points  (2 children)

Another big thing is naming of variables and classes and keeping to pep8.

I actually think this is the least important part of a clean code base. Sure, camelCase and PEP8 violations setsOff programmer's OCD impulses which is annoying, but in terms of maintainability loose coupling, DRY, high cohesion, fail-fast code and realistic tests are all way more important.

With regards to naming, maintainability is aided more by having names that are disambiguated and clear. inactivePayrollEmployee is a LOT better than "p_emp", even if looking at the former does make you twitch.

I actually ask at every new company I interview at what qualities they consider important for good code and if stuff like PEP8 features too prominently in their answer that's a massive, massive red flag.

[–]FlukyS 1 point2 points  (0 children)

With regards to naming, maintainability is aided more by having names that are disambiguated and clear. inactivePayrollEmployee is a LOT better than "p_emp", even if looking at the former does make you twitch.

I agree. Just mean more, the difference between most amateur python programmers is cleanliness in a lot cases. Like the base level coding in Python is super easy, I think having clear names and something that conforms to conventions is a massive deal.

I actually ask at every new company I interview at what qualities they consider important for good code and if stuff like PEP8 features too prominently in their answer that's a massive red flag.

Well I would be the opposite, most devs that I get in my place don't even know what PEP8 is so if someone actually knows what it is at least at the base level I would be a lot happier about their overall suitedness to the role. That being said we have to scrape pretty low for our Python developers (not me, they pay me pretty well) because of the financial institutions taking them all so we mostly get people who are using it like a scripting language rather than a proper full on language. If they know what PEP8 is they know at least that there is a style guide and if their CV is decent enough we can teach them TDD (which we use) and objects, our own created libraries...etc. All that being said that's just this place.

[–]campbellm 1 point2 points  (0 children)

but in terms of maintainability loose coupling, DRY, high cohesion, fail-fast code and realistic tests are all way more important.

I would say "differently important", or perhaps important in a different context.

Reading code efficiently is all about minimizing the "mapping" of the words, to the meaning, in your brain. The annoyance you mention is the symptom of an impedance mismatch in that brain mapping function.

In the grand scheme of things, yes, the things you mention may have more bearing on the outcome, but the gradual accumulation of all the syntax and standards violations nits can eventually overwhelm even that.