3 ms·

Developers that write unmaintainable and unreadable code exist. This has nothing to do with the language. That's where "Good Developers" come in. You don't e

Developers that write unmaintainable and unreadable code exist. This has nothing to do with the language. That's where "Good Developers" come in. You don't even need to know how to write code to understand the code written at Crowdtilt or any other company that really uses Modern Perl and have good practices.

mamcx 14y ago
Yeah, but the language helps a lot on that. And so, it is related to the language. Comparing the readability of python vs perl/c-like languages show it clearly. In python the readability come as a natural idiom, it is part of their zen!. I found that when I develop in python/delphi/pascal the code is readable by default, but in ANY c-derived language could become messy fast. Something as simply as how align a IF clause. In C-like language I could go wild (and I see a LOT of code that look different, from person to person) and in contrast I read almost any python code as if I was write by myself.
- chromatic 14y ago
  In python the readability come as a natural idiom, it is part of their zen! Superficial readability, perhaps. Neither PEP 8 nor PEP 20 get into interesting questions about maintainability like: * How long should individual compilation units be? * How do I factor my code? * What metaphors do I use to name components? * How do I know when to break apart components? * How do I know when to merge components? * How do I write effective documentation? * Is this API easy to use? * Have I sufficiently encapsulated this component? * How easy is this code to test? * Does this code match local style? * Does this code follow the idioms and express the necessary elements of the problem domain effectively? * Is it easy to misuse this API? * Have I made too much information public? * Have I made too little information public? * Does this code make potential bugs screechingly obvious? * Do I handle potential error conditions sensibly and completely? * How much work do I face enhancing this code in the future? PEP 8 concerns itself with far less interesting things, like why vertical alignment is annoying. In my experience, that's one of the least substantial elements contributing to maintainability. As for readability, it doesn't really matter if someone who doesn't know the language can't read it.
  - j-kidd 14y ago
    You need good developers to tackle those interesting questions. There is no answer, because you can only rely on rule of thumb and you must know when to break the rule of thumb. PEP 8, on the other hand, is to get these good developers to agree on the less interesting things, such that they can use it as a stepping stone to the more interesting ones. PEP 8 requires strict compliance, because if different developer ignore different portion of PEP 8, you end up with nothing. In short, if you have long lines of code crammed together with no spacing, get them to look pretty based on PEP 8 first before we talk about how easy is this code to test.
    - chromatic 14y ago
      I agree, but nothing in Python the language addresses any of my questions. Those concerns are so far beyond the language level that the language is irrelevant.

mamcx 14y ago

Yeah, but the language helps a lot on that. And so, it is related to the language. Comparing the readability of python vs perl/c-like languages show it clearly. In python the readability come as a natural idiom, it is part of their zen!. I found that when I develop in python/delphi/pascal the code is readable by default, but in ANY c-derived language could become messy fast. Something as simply as how align a IF clause. In C-like language I could go wild (and I see a LOT of code that look different, from person to person) and in contrast I read almost any python code as if I was write by myself.

chromatic 14y ago
In python the readability come as a natural idiom, it is part of their zen! Superficial readability, perhaps. Neither PEP 8 nor PEP 20 get into interesting questions about maintainability like: * How long should individual compilation units be? * How do I factor my code? * What metaphors do I use to name components? * How do I know when to break apart components? * How do I know when to merge components? * How do I write effective documentation? * Is this API easy to use? * Have I sufficiently encapsulated this component? * How easy is this code to test? * Does this code match local style? * Does this code follow the idioms and express the necessary elements of the problem domain effectively? * Is it easy to misuse this API? * Have I made too much information public? * Have I made too little information public? * Does this code make potential bugs screechingly obvious? * Do I handle potential error conditions sensibly and completely? * How much work do I face enhancing this code in the future? PEP 8 concerns itself with far less interesting things, like why vertical alignment is annoying. In my experience, that's one of the least substantial elements contributing to maintainability. As for readability, it doesn't really matter if someone who doesn't know the language can't read it.
- j-kidd 14y ago
  You need good developers to tackle those interesting questions. There is no answer, because you can only rely on rule of thumb and you must know when to break the rule of thumb. PEP 8, on the other hand, is to get these good developers to agree on the less interesting things, such that they can use it as a stepping stone to the more interesting ones. PEP 8 requires strict compliance, because if different developer ignore different portion of PEP 8, you end up with nothing. In short, if you have long lines of code crammed together with no spacing, get them to look pretty based on PEP 8 first before we talk about how easy is this code to test.
  - chromatic 14y ago
    I agree, but nothing in Python the language addresses any of my questions. Those concerns are so far beyond the language level that the language is irrelevant.