7 ms·

When I first started working after college I had a lot to learn. For some of the first bug fixes or small feature enhancements I had, I remember fixing it with

When I first started working after college I had a lot to learn. For some of the first bug fixes or small feature enhancements I had, I remember fixing it with a one line change, and consequently being so frustrated with the senior code reviewer who would recommend I do some major refactoring instead. I now see that it's not about doing things minimally, but doing things as correctly and clearly as possible. And one should never be afraid to refactor! (Obviously there are cases where single line changes are the correct solution; but back then my mindset was "how can I do this with as little change as possible" and it should have been "as clearly as possible")

amelius 10y ago
It makes me wonder why programming languages (and/or their development environments) are not designed for refactoring. Refactoring should be as simple as possible.
- caseymarquis 10y ago
  In what way are they not designed as such? The biggest issue I can think of regarding major refactoring is coordinating across the team and ensuring you're collectively at a good point to start changing things. That's not really a language/tooling issue.
  - fstephany 10y ago
    For everyday operations and refactoring, I find the tools to be the limiting factor. I've just finished a contract where we had to deal with legacy code on iOS and Android (yes, it exists. Let two junior programmers not very keen to learn from the outside during 5 years working on the app and see with what you end up). Refactoring the Android code to a healthy state was greatly facilitated by Android Studio and the whole IntelliJ suite. We were not afraid to move things around and could always see the light at the end of the tunnel. On the other side, XCode has been a pain in the ass for the whole project. We had ObjC and Swift coode. Good luck with that. Even the pure Swift was hard to refactor. SourceKit is great and should help to get a top notch IDE that can resonate about source code but somehow Apple does not seem to care about the tools. Sorry, I get passionate when talking about refactoring and tools. Another example is how the Pharo Project (http://pharo.org/ http://pharo.org/) is refactoring the Squeak source (http://squeak.org/ http://squeak.org/) code/architecture. They developed custom tools for this purpose and their code cleaning is quite impressive when you know where they are coming from.
- js8 10y ago
  Actually, I believe refactoring should be done by computers. But people will hate it when we will have that capability.
  - crdoconnor 10y ago
    Cleaning up code requires way too much human judgment for that to be possible any time soon.
    - js8 10y ago
      Well, I have this idea that, pretty much, smaller programs (in the sense of Kolmogorov complexity) are well-written and thus maintainable. More precise argument is as follows: You take a very simple functional language, like say, Haskell Core. Let's consider a large and representative enough (finite) set of programs in this language. We find the smallest possible (or very small) representation of this set. This will involve definition of some commonly used functions. Let's call all the functions that are in this representation "the basic library". Then, for a new program, we can try to find shortest possible (among those you're able to consider) representation, such that, using the functions from the basic library comes for free (so you don't count the size of functions in the basic library towards the total size of the new program). So if we can write a program that would be able to find smaller representation using definitions (functions) that we already generated in that representative set, I think it would essentially automatically refactor code to be more readable and maintainable.
      - crdoconnor 10y ago
        This might get you the shortest code but it wouldn't necessarily get you the cleanest code. There's often a trade off between coupling and terseness which requires (human) judgement in order to balance the competing concerns correctly. There's also the matter of using appropriate metaphors. I have a feeling that a "cleaner" optimized like this would get you a program full of the equivalent of perl one liners, assuming it's even possible.
        10y ago
- hasbot 10y ago
  IntelliJ is designed for refactoring. I'm not sure how a programming language could be designed for refactoring. What would that look like?
  - AstralStorm 10y ago
    Said language would make contracts easy to write and first class citizens. It would help you formalize parts of the typically non-formal programming, allowing automated or semi-automated formal verification. The language would allow you to bypass accidental hard restrictions imposed by type system - essentially duck typed but only if formal requirements are met on the types. Hey, I've described Isabelle/HOL; another language that is pretty close but more typical looking is Pyret.
- pythonaut_16 10y ago
  I know easy refactoring is an explicit goal of the Elm programming language. http://elm-lang.org/ http://elm-lang.org/
  - AstralStorm 10y ago
    Semantic versioning is nice but not fine grained enough, and does not help the programmer who is deriving the new version at all.
Cthulhu_ 10y ago
I prefer to split functional changes and refactorings in separate pull requests. First do a round of cleanup and refactoring, which is almost always necessary for any code older than what you wrote five minutes ago. Then in a separate PR, do the actual work. Mind you, this is also in part due to traceability; I want to be able to point to a PR and go 'this is where this functionality was changed', with all the details. That makes it easier for the reviewer too, easier to find and review the actual change if it's the only change in a PR than when it's hidden in the diff alongside a major refactoring. I've also seen another open source project that said "please, no refactoring PRs". I can see the value in that one too - code is never perfect, and you can continuously polish but it won't actually achieve much, besides causing a lot of churn in your codebase.
- jalfresi 10y ago
  I've seen this expressed as "make the change easy; then make the easy change"

amelius 10y ago

It makes me wonder why programming languages (and/or their development environments) are not designed for refactoring. Refactoring should be as simple as possible.

caseymarquis 10y ago
In what way are they not designed as such? The biggest issue I can think of regarding major refactoring is coordinating across the team and ensuring you're collectively at a good point to start changing things. That's not really a language/tooling issue.
- fstephany 10y ago
  For everyday operations and refactoring, I find the tools to be the limiting factor. I've just finished a contract where we had to deal with legacy code on iOS and Android (yes, it exists. Let two junior programmers not very keen to learn from the outside during 5 years working on the app and see with what you end up). Refactoring the Android code to a healthy state was greatly facilitated by Android Studio and the whole IntelliJ suite. We were not afraid to move things around and could always see the light at the end of the tunnel. On the other side, XCode has been a pain in the ass for the whole project. We had ObjC and Swift coode. Good luck with that. Even the pure Swift was hard to refactor. SourceKit is great and should help to get a top notch IDE that can resonate about source code but somehow Apple does not seem to care about the tools. Sorry, I get passionate when talking about refactoring and tools. Another example is how the Pharo Project (http://pharo.org/ http://pharo.org/) is refactoring the Squeak source (http://squeak.org/ http://squeak.org/) code/architecture. They developed custom tools for this purpose and their code cleaning is quite impressive when you know where they are coming from.
js8 10y ago
Actually, I believe refactoring should be done by computers. But people will hate it when we will have that capability.
- crdoconnor 10y ago
  Cleaning up code requires way too much human judgment for that to be possible any time soon.
  - js8 10y ago
    Well, I have this idea that, pretty much, smaller programs (in the sense of Kolmogorov complexity) are well-written and thus maintainable. More precise argument is as follows: You take a very simple functional language, like say, Haskell Core. Let's consider a large and representative enough (finite) set of programs in this language. We find the smallest possible (or very small) representation of this set. This will involve definition of some commonly used functions. Let's call all the functions that are in this representation "the basic library". Then, for a new program, we can try to find shortest possible (among those you're able to consider) representation, such that, using the functions from the basic library comes for free (so you don't count the size of functions in the basic library towards the total size of the new program). So if we can write a program that would be able to find smaller representation using definitions (functions) that we already generated in that representative set, I think it would essentially automatically refactor code to be more readable and maintainable.
    - crdoconnor 10y ago
      This might get you the shortest code but it wouldn't necessarily get you the cleanest code. There's often a trade off between coupling and terseness which requires (human) judgement in order to balance the competing concerns correctly. There's also the matter of using appropriate metaphors. I have a feeling that a "cleaner" optimized like this would get you a program full of the equivalent of perl one liners, assuming it's even possible.
      - 10y ago
hasbot 10y ago
IntelliJ is designed for refactoring. I'm not sure how a programming language could be designed for refactoring. What would that look like?
- AstralStorm 10y ago
  Said language would make contracts easy to write and first class citizens. It would help you formalize parts of the typically non-formal programming, allowing automated or semi-automated formal verification. The language would allow you to bypass accidental hard restrictions imposed by type system - essentially duck typed but only if formal requirements are met on the types. Hey, I've described Isabelle/HOL; another language that is pretty close but more typical looking is Pyret.
pythonaut_16 10y ago
I know easy refactoring is an explicit goal of the Elm programming language. http://elm-lang.org/ http://elm-lang.org/
- AstralStorm 10y ago
  Semantic versioning is nice but not fine grained enough, and does not help the programmer who is deriving the new version at all.

Cthulhu_ 10y ago

I prefer to split functional changes and refactorings in separate pull requests. First do a round of cleanup and refactoring, which is almost always necessary for any code older than what you wrote five minutes ago. Then in a separate PR, do the actual work. Mind you, this is also in part due to traceability; I want to be able to point to a PR and go 'this is where this functionality was changed', with all the details. That makes it easier for the reviewer too, easier to find and review the actual change if it's the only change in a PR than when it's hidden in the diff alongside a major refactoring. I've also seen another open source project that said "please, no refactoring PRs". I can see the value in that one too - code is never perfect, and you can continuously polish but it won't actually achieve much, besides causing a lot of churn in your codebase.

jalfresi 10y ago
I've seen this expressed as "make the change easy; then make the easy change"