It's not a matter of which one I like best, it's a matter of following the code conventions of the language I'm writing at the moment, this makes the code more readable for other programmers using the same language within the organization.
For instance, in Python, if you don't follow PEP8 (which is the one defining the code conventions) your code might be difficult to read, for example:
In this dummy code snippet, if we know it's following PEP8, we know that UserProfileand OperationResultHandler are a classes, not a functions, if PEP8 wasn't enforced, I would have to go to where each symbol is defined to find out whether they are classes or functions so that I read (and edit) the code with more confidence. Moreover, any new joiner familiar with python will be able to read it without going back and forth to each symbol definition because it follows the agreed code convention.
To me, it's not a matter of choosing the convention for your project and sticking to it, it's about getting familiar with the convention for the language you're using and following it.
Very well demonstrated! I used to be an adamant camelCase advocate (coming from JavaScript). When I went into Rust (which uses snake_case), I was horrified by the language convention. It took me a while to accept that it's just better to go with language conventions than to fight the community norms.
@somedood
I went through something similar! When I was learning JS/TS and then went to Python and Rust, I found it hard to use snake_case since I was used to camelCase. Since I didn't want to have countless warnings from the compiler, I used snake_case.
I agree with that😁, we must follow the language conventions that we are working with. It's the best way to build consistent and clear code for a project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's not a matter of which one I like best, it's a matter of following the code conventions of the language I'm writing at the moment, this makes the code more readable for other programmers using the same language within the organization.
For instance, in Python, if you don't follow PEP8 (which is the one defining the code conventions) your code might be difficult to read, for example:
In this dummy code snippet, if we know it's following PEP8, we know that
UserProfileandOperationResultHandlerare a classes, not a functions, if PEP8 wasn't enforced, I would have to go to where each symbol is defined to find out whether they are classes or functions so that I read (and edit) the code with more confidence. Moreover, any new joiner familiar with python will be able to read it without going back and forth to each symbol definition because it follows the agreed code convention.To me, it's not a matter of choosing the convention for your project and sticking to it, it's about getting familiar with the convention for the language you're using and following it.
I agree, use what the language standards are and stay consistent!
Very well demonstrated! I used to be an adamant camelCase advocate (coming from JavaScript). When I went into Rust (which uses snake_case), I was horrified by the language convention. It took me a while to accept that it's just better to go with language conventions than to fight the community norms.
@somedood I went through something similar! When I was learning JS/TS and then went to Python and Rust, I found it hard to use snake_case since I was used to camelCase. Since I didn't want to have countless warnings from the compiler, I used snake_case.
I agree with that😁, we must follow the language conventions that we are working with. It's the best way to build consistent and clear code for a project.