Let Internet sites message members/customers directly, instead of unreliable, insecure email or costly custom apps. 100% open source. Contributors welcome!
It's a simplistic, insulting way to criticize someone else's work, often stemming from an inconsequential difference of opinion. You should never tell someone that.
If you have a considered critique, explain politely why a solution may not meet its known requirements, or could break down in future conditions. (You may be wrong, after all.)
There is far too much arrogance and mean-spiritedness in online software communities.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I agree there's certain arrogance. But good of bad code is not just a matter of opinion.
There so much written about it.
I've written a series of 56 code smells (so far). They all show the problems and all of them show solutions. It is not just criticizing others work but to build amazing software
I don't know if that's entirely fair, but I must assume that that has been your experience so far?
Personally, I dislike the term "code smell", but I appreciate the concept it's trying to convey. Yes, it can be a blunt tool used by developers who blindly follow coding standards dogmatically, but even Robert Martin himself argues against that.
In terms of the code review usage, I take the approach that anything I make a comment on is something that I would be ok if someone left the same (or equivalent) comment on some of my own code during a review. Code reviews should never be used by a senior (either in general development terms or in a specific language) developer to try and show up one who is less senior. They're a place to learn, and that goes both ways. They should also be treated like any face-to-face conversation in that rudeness should be unacceptable. Besides, being civil to people always gets better results than rudeness.
So, I hope you're not completely put off by the concept of a "code smell" (again, I think it's a poor naming choice) because it really can lead any developer to be better when the concept is used appropriately.
When someone is really good at something, like a footballer (or basket ball player if you're American), what that means is that they have been in so many and varied footballing (or basket balling) situations that they have learnt how best to act in those situations. We often call that instinct, because of how fast they can apply what they have learnt.
So if a really experienced footballer looks over a field of players, they will be able to see when someone is stood in the wrong position or is making the wrong play. They might not be able to fully explain how they know, but they can feel it.
So even though nothing bad might happen because of what is going on on the field in the moment, something bad might happen later because of it, maybe the team loses possession, or a player ends up offside.
You might call that a "play smell" because the experienced player can sense something isn't right, even though nothing bad is immediately evident, like how you can smell smoke before you can see a fire.
A code smell is a lot like that. An experienced programmer can look over code, maybe even their own, and see over complexity or other inefficiencies in the making.
The code is beginning to smell.
A lot of code smells are so frequently done by less experienced or very tired programmers that the types of smell can be documented, which is why you often see blog posts about how "[this code pattern] is a code smell".
It's something that's not broken, but looks like it could be.
If the flour smells when you're baking a cake, it might be fine, or it might explode in the oven. Until you know what's causing the smell, you're at risk of a big mess when you least expect it.
Code Smells are like a disease that infects your code and makes it smell bad. They might slow your program down or even crash it.
Or
Some programmers have a term they use for the parts of a computer program that might not work well. They call these parts "code smells." Bad code smells are like a stink coming from a garbage can
Code is said to "smell" when it doesn't follow best practices, isn't idiomatic (not standard), or is likely to be error prone.
To me, it's a lazy (and often condescending) way to describe issues in a code. "That has a bad smell." Well, why? Elaborate.
Sometimes it means an intuition that something can be improved, but the reviewer lacks the vocabulary to say why or how.
For example if you have code that is supposed to determine the state of a button based on user interaction, and it's 500 lines of code, something is definitely wrong there, that code is going to "smell". An experienced engineer might recommend better design patterns, give ideas how to reduce the complexity, illuminate a path towards something more elegant, maintainable, and most importantly, stable.
When you’ve spent a lot of time making things, for example, Lego constructions you’ll begin to see things that while they work, they aren’t very stable or safe over the long term. It’s a form of instinct that you learn when you develop your skills with a system.
You wouldn’t put a laser tower on top of a tall stack of 2-stud bricks if you wanted the tower to withstand an alien attack. If you saw that you’d probably want to put the towers on several stacks of 8-stud bricks. Take that aliens!
Code smells are like that. When you look at code and can see things you know don’t work when the system gets larger or things that will lead to tight binding between separate systems. Those are code smells.
Just because you think a piece of code is smelly doesn’t mean that the code is bad. It does mean you should talk about the code nicely with someone else and find out it’s story if you can. Your code might be the work of many people over a long time and there’s probably a reason that it looks like that.
Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
Something in the code that when read creates a reaction similar to catching a whiff of the city sanitation plant. You may not inherently know what's wrong with it (you may) but there is just something that seems wrong about the logic.
"Code smell" is a term to thrash-talk code without bringing up constructive criticism about its implications on security, performance or maintainability.
There are things in code which have a 'bad smell'. They may not always be bad by themselves, but they're a sign that there might be a larger problem. A warning sign.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
It's a simplistic, insulting way to criticize someone else's work, often stemming from an inconsequential difference of opinion. You should never tell someone that.
If you have a considered critique, explain politely why a solution may not meet its known requirements, or could break down in future conditions. (You may be wrong, after all.)
There is far too much arrogance and mean-spiritedness in online software communities.
I agree there's certain arrogance. But good of bad code is not just a matter of opinion.
There so much written about it.
I've written a series of 56 code smells (so far). They all show the problems and all of them show solutions. It is not just criticizing others work but to build amazing software
I don't know if that's entirely fair, but I must assume that that has been your experience so far?
Personally, I dislike the term "code smell", but I appreciate the concept it's trying to convey. Yes, it can be a blunt tool used by developers who blindly follow coding standards dogmatically, but even Robert Martin himself argues against that.
In terms of the code review usage, I take the approach that anything I make a comment on is something that I would be ok if someone left the same (or equivalent) comment on some of my own code during a review. Code reviews should never be used by a senior (either in general development terms or in a specific language) developer to try and show up one who is less senior. They're a place to learn, and that goes both ways. They should also be treated like any face-to-face conversation in that rudeness should be unacceptable. Besides, being civil to people always gets better results than rudeness.
So, I hope you're not completely put off by the concept of a "code smell" (again, I think it's a poor naming choice) because it really can lead any developer to be better when the concept is used appropriately.
When someone is really good at something, like a footballer (or basket ball player if you're American), what that means is that they have been in so many and varied footballing (or basket balling) situations that they have learnt how best to act in those situations. We often call that instinct, because of how fast they can apply what they have learnt.
So if a really experienced footballer looks over a field of players, they will be able to see when someone is stood in the wrong position or is making the wrong play. They might not be able to fully explain how they know, but they can feel it.
So even though nothing bad might happen because of what is going on on the field in the moment, something bad might happen later because of it, maybe the team loses possession, or a player ends up offside.
You might call that a "play smell" because the experienced player can sense something isn't right, even though nothing bad is immediately evident, like how you can smell smoke before you can see a fire.
A code smell is a lot like that. An experienced programmer can look over code, maybe even their own, and see over complexity or other inefficiencies in the making.
The code is beginning to smell.
A lot of code smells are so frequently done by less experienced or very tired programmers that the types of smell can be documented, which is why you often see blog posts about how "[this code pattern] is a code smell".
It's something that's not broken, but looks like it could be.
If the flour smells when you're baking a cake, it might be fine, or it might explode in the oven. Until you know what's causing the smell, you're at risk of a big mess when you least expect it.
Code Smells are like a disease that infects your code and makes it smell bad. They might slow your program down or even crash it.
Or
Some programmers have a term they use for the parts of a computer program that might not work well. They call these parts "code smells." Bad code smells are like a stink coming from a garbage can
Code is said to "smell" when it doesn't follow best practices, isn't idiomatic (not standard), or is likely to be error prone.
To me, it's a lazy (and often condescending) way to describe issues in a code. "That has a bad smell." Well, why? Elaborate.
Sometimes it means an intuition that something can be improved, but the reviewer lacks the vocabulary to say why or how.
For example if you have code that is supposed to determine the state of a button based on user interaction, and it's 500 lines of code, something is definitely wrong there, that code is going to "smell". An experienced engineer might recommend better design patterns, give ideas how to reduce the complexity, illuminate a path towards something more elegant, maintainable, and most importantly, stable.
When you’ve spent a lot of time making things, for example, Lego constructions you’ll begin to see things that while they work, they aren’t very stable or safe over the long term. It’s a form of instinct that you learn when you develop your skills with a system.
You wouldn’t put a laser tower on top of a tall stack of 2-stud bricks if you wanted the tower to withstand an alien attack. If you saw that you’d probably want to put the towers on several stacks of 8-stud bricks. Take that aliens!
Code smells are like that. When you look at code and can see things you know don’t work when the system gets larger or things that will lead to tight binding between separate systems. Those are code smells.
Just because you think a piece of code is smelly doesn’t mean that the code is bad. It does mean you should talk about the code nicely with someone else and find out it’s story if you can. Your code might be the work of many people over a long time and there’s probably a reason that it looks like that.
Your finger hurts when you touch things. It is probably broken.
You can "smell" you code stink when it wasn't written properly.
The smell is just an indication. Some smells you recognize better than others.
Something in the code that when read creates a reaction similar to catching a whiff of the city sanitation plant. You may not inherently know what's wrong with it (you may) but there is just something that seems wrong about the logic.
"Code smell" is a term to thrash-talk code without bringing up constructive criticism about its implications on security, performance or maintainability.
Like a cake can eat but not delicious.
There are things in code which have a 'bad smell'. They may not always be bad by themselves, but they're a sign that there might be a larger problem. A warning sign.
Code did a poo poo
When somebody thinks this is a bad code, but can't explain why
yes
Here you have 56. Choose your weapon
Code Smell 53 - Explicit Iteration
Maxi Contieri ・ Jan 5 ・ 1 min read
dev.to/mcsee/series/9470
code smell: code that seems to be working perfect, but hides a problem that can occur in the future