Skip to main content
deleted 80 characters in body
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to "evolve it" or changeevolve it (except they are working as mathematician in that field and try to change or improve the algo). Their typicalstandard goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, I would recommend to follow the text book as close as possible, which typically means not to refactor.

However, for someone working as mathematician in that field who is really workingtrying to work on that algorithm and trying to change or improve it, IMHO splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier like for any other kind of code as well.

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to "evolve it" or change it (except they are working as mathematician in that field and try to change or improve the algo). Their typical goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, I would recommend to follow the text book as close as possible, which typically means not to refactor.

However, for someone who is really working on that algorithm and trying to change or improve it, IMHO splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier like for any other kind of code as well.

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to evolve it. Their standard goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, I would recommend to follow the text book as close as possible, which typically means not to refactor.

However, for someone working as mathematician in that field who is trying to work on that algorithm and change or improve it, IMHO splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier like for any other kind of code as well.

deleted 115 characters in body
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to "evolve it" or change it (except they are working as mathematician in that field and try to change or improve the algo). Their typical goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, breaking down the functions into smaller one can make it harder to compare the implementation code with the text book. In such a case, I would recommend not to refactor, but follow the text book as close as possible, which typically means not to refactor.

However, for someone who is really working on that algorithm and trying to change or improve it, I thinkIMHO splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier as well aslike for any other kind of code as well.

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to "evolve it" or change it (except they are working as mathematician in that field and try to change or improve the algo). Their typical goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, breaking down the functions into smaller one can make it harder to compare the implementation code with the text book. In such a case, I would recommend not to refactor, but follow the text book as close as possible.

However, for someone who is really working on that algorithm and trying to change or improve it, I think splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier as well as for any other kind of code.

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to "evolve it" or change it (except they are working as mathematician in that field and try to change or improve the algo). Their typical goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, I would recommend to follow the text book as close as possible, which typically means not to refactor.

However, for someone who is really working on that algorithm and trying to change or improve it, IMHO splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier like for any other kind of code as well.

Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625

"Clean code" is not an end in itself, it is a means to an end. The main purpose of refactoring bigger functions into smaller ones and cleaning up the code in other ways is to keep the code evolvable and maintainable.

When picking such a very specific mathematical algorithm like the "Miller-Rabin" prime test from a text book, most programmers do not want to "evolve it" or change it (except they are working as mathematician in that field and try to change or improve the algo). Their typical goal is to transfer it from the pseudo code of the text book correctly into the programming language of their environment. For this purpose, breaking down the functions into smaller one can make it harder to compare the implementation code with the text book. In such a case, I would recommend not to refactor, but follow the text book as close as possible.

However, for someone who is really working on that algorithm and trying to change or improve it, I think splitting up this function into smaller, well named ones, or replacing the bunch of "magic numbers" by named constants, can help to make changes to the code easier as well as for any other kind of code.