Skip to main content
Code Review

Return to Answer

added 3 characters in body
Source Link
G. Sliepen
G. Sliepen
  • 69.3k
  • 8
  • 8

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by Mastlukstru, avoid overly long functions. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by Mast, avoid overly long functions. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by lukstru, avoid overly long functions. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.

edited body
Source Link
G. Sliepen
G. Sliepen
  • 69.3k
  • 8
  • 8

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by Mast, try to keepavoid overly long functions short. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by Mast, try to keep functions short. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by Mast, avoid overly long functions. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.

Source Link
G. Sliepen
G. Sliepen
  • 69.3k
  • 8
  • 8

Write idiomatic code

Try to write code that follows the same practices as the majority of the other code written for your programming language, including its standard library. This includes both naming and code style. Doing so helps others feel more familiar.

When creating custom functions or classes that do something similar to what is in the standard library of your language, try to make them work exactly the same way. This allows your code to be used as drop-in replacements, and also follows the principle of least surprise.

Proper code density

As mentioned by Mast, try to keep functions short. But apart from that, don't be afraid to add empty lines to your functions and class definitions to clearly separate various sections.

Also try to avoid overly long lines, as this makes the code harder to read in most editors, as you either have to start scrolling horizontally, or lines are wrapped in ugly ways. Some projects mandate a strict line length limit. I would not go that far, but you can often reduce the length of a line by splitting long expressions into multiple expressions, for example by introducing temporary variables for partial results. Sometimes you have names of types, variables or functions that are very long, and this in turn causes very long lines. If your language supports it, consider creating short aliases for them to make the code easier to read.

Prefer generic code

Projects often begin small, doing only one thing, like writing a string to a database using a function write_string_to_database(). But projects grow, and maybe you want to write numbers or other things as well. It is easy to create more variations of the first function to handle all these types, but this results in a lot of code that has to be maintained. In such a case, if your language supports it, find more generic ways to structure your code. Perhaps a write_to_database() that can take strings, numbers and other things as parameters.