Skip to main content
some formatting and language changes.
Source Link
Edgar Bonet
  • 1.3k
  • 1
  • 7
  • 6

Physicist here. Been there.

I would argue that your problem is lessnot about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's more about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all of this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say a good IDE (JetBrains PyCharm also has a free community edition) and version control areis the most useful.

Physicist here. Been there.

I would argue that your problem is less about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's more about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all of this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say a good IDE (JetBrains PyCharm also has a free community edition) and version control are the most useful.

Physicist here. Been there.

I would argue that your problem is not about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all of this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say version control is the most useful.

some formatting and language changes. Also an additional suggestion for tools of programming.
Source Link

Physicist here. Been there.

I would argue that youyour problem is notless about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's more about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all of this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say a good IDE (JetBrains PyCharm also has a free community edition) and version control isare the most useful.

Physicist here. Been there.

I would argue that you problem is not about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's more about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say version control is the most useful.

Physicist here. Been there.

I would argue that your problem is less about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's more about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all of this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say a good IDE (JetBrains PyCharm also has a free community edition) and version control are the most useful.

Mod Moved Comments To Chat
Bounty Awarded with 50 reputation awarded by jpmc26
Source Link
Edgar Bonet
  • 1.3k
  • 1
  • 7
  • 6

Physicist here. Been there.

I would argue that you problem is not about the choice of tools or programming paradigms (unit testing, OOP, whatever). It's more about the attitude, the mindset. The fact the your variable names are well chosen at first and end up being crap is revealing enough. If you think of your code as “run once, then throw away”, then it will inevitably be a mess. If you think of it as the product of craft and love, it will be beautiful.

I believe there is only one recipe for writing clean code: write it for the human being who is going to read it, not for the interpreter that is going to run it. The interpreter doesn't care if your code is a mess, but the human reader does care.

You are a scientist. You probably can spend a lot of time polishing a scientific article. If your first draft looks convoluted, you will refactor it until the logic just flows in the most natural way. You want your colleagues to read it and find the arguments crystal clear. You want your students to be a able to learn from it.

Writing clean code is exactly the same. Think of your code as a detailed explanation of an algorithm that only incidentally happens to be machine-readable. Imagine you are going to publish it as an article that people will read. You are even going to show it at a conference and walk the audience through it line by line. Now rehearse your presentation. Yes, line by line! Embarrassing, isn't it? So clean up your slides (err... I mean, your code), and rehearse again. Repeat until you are happy with the result.

It would be still better if, after the rehearsals, you can show your code to real people rather than just imaginary people and your future self. Going through it line by line is called a “code walk”, and it's not a silly practice.

Of course, all this comes at a cost. Writing clean code takes a lot more time than writing throwaway code. Only you can evaluate whether the benefits outweigh the cost for your particular use case.

As for the tools, I said before they are not that important. However, if I had to choose one, I would say version control is the most useful.