Skip to main content
Fixed explaination on regions
Source Link
Jeff Vanzella
  • 4.3k
  • 2
  • 24
  • 33

White space and Casing is good.

Just a few things to think about:

  1. #region is a code smellnot very well accepted. If you have to use #region, then you should look at pullingmoving the code out into a method or its own class.
  2. Use var instead of explicit declarations for obvious variables. This makes the code much easier to scan over.
  3. If you insist on comments to explain what the method is doing, us the C# /// syntax. This does a couple of things: it allows intellisense to pick up the description when using the library, and there are tools that can take the /// comments and create API help documentation.
  4. General practice in C# is to use either m_ or _ at the beginning of class variables. This eliminates the need to use this., which clutters up the code a little.
  5. Be consistent with your use of { } after if statements. It makes it eaasier to focus on the logic when it doesn't have to process changes in the formatting.
  6. In the line thread.Name = "Client" + i; I would make "Client" a constant.
  7. Separate concerns. For instance: Console.WriteLine does not belong in your server class.
  8. If the constructor doesn't do anything, get rid of it, it is only adding noise to your class.
  9. In my opinion, class variables should be initialized in the constructor, not on declaration.
  10. Use meaningful names for variables: a does not portray what the variable does. tcpClient on the other hand does. This makes your methods much easier to read.
  11. getClient should be GetClient. C# naming conventions

Most of these are minor, and don't affect the application, they just add that little bit to your code, and will make it easier to read and maintain in the future.

White space and Casing is good.

Just a few things to think about:

  1. #region is a code smell. If you have to use #region, then you should look at pulling the code out into a method.
  2. Use var instead of explicit declarations for obvious variables. This makes the code much easier to scan over.
  3. If you insist on comments to explain what the method is doing, us the C# /// syntax. This does a couple of things: it allows intellisense to pick up the description when using the library, and there are tools that can take the /// comments and create API help documentation.
  4. General practice in C# is to use either m_ or _ at the beginning of class variables. This eliminates the need to use this., which clutters up the code a little.
  5. Be consistent with your use of { } after if statements. It makes it eaasier to focus on the logic when it doesn't have to process changes in the formatting.
  6. In the line thread.Name = "Client" + i; I would make "Client" a constant.
  7. Separate concerns. For instance: Console.WriteLine does not belong in your server class.
  8. If the constructor doesn't do anything, get rid of it, it is only adding noise to your class.
  9. In my opinion, class variables should be initialized in the constructor, not on declaration.
  10. Use meaningful names for variables: a does not portray what the variable does. tcpClient on the other hand does. This makes your methods much easier to read.
  11. getClient should be GetClient. C# naming conventions

Most of these are minor, and don't affect the application, they just add that little bit to your code, and will make it easier to read and maintain in the future.

White space and Casing is good.

Just a few things to think about:

  1. #region is not very well accepted. If you have to use #region, then you should look at moving the code out into a method or its own class.
  2. Use var instead of explicit declarations for obvious variables. This makes the code much easier to scan over.
  3. If you insist on comments to explain what the method is doing, us the C# /// syntax. This does a couple of things: it allows intellisense to pick up the description when using the library, and there are tools that can take the /// comments and create API help documentation.
  4. General practice in C# is to use either m_ or _ at the beginning of class variables. This eliminates the need to use this., which clutters up the code a little.
  5. Be consistent with your use of { } after if statements. It makes it eaasier to focus on the logic when it doesn't have to process changes in the formatting.
  6. In the line thread.Name = "Client" + i; I would make "Client" a constant.
  7. Separate concerns. For instance: Console.WriteLine does not belong in your server class.
  8. If the constructor doesn't do anything, get rid of it, it is only adding noise to your class.
  9. In my opinion, class variables should be initialized in the constructor, not on declaration.
  10. Use meaningful names for variables: a does not portray what the variable does. tcpClient on the other hand does. This makes your methods much easier to read.
  11. getClient should be GetClient. C# naming conventions

Most of these are minor, and don't affect the application, they just add that little bit to your code, and will make it easier to read and maintain in the future.

Source Link
Jeff Vanzella
  • 4.3k
  • 2
  • 24
  • 33

White space and Casing is good.

Just a few things to think about:

  1. #region is a code smell. If you have to use #region, then you should look at pulling the code out into a method.
  2. Use var instead of explicit declarations for obvious variables. This makes the code much easier to scan over.
  3. If you insist on comments to explain what the method is doing, us the C# /// syntax. This does a couple of things: it allows intellisense to pick up the description when using the library, and there are tools that can take the /// comments and create API help documentation.
  4. General practice in C# is to use either m_ or _ at the beginning of class variables. This eliminates the need to use this., which clutters up the code a little.
  5. Be consistent with your use of { } after if statements. It makes it eaasier to focus on the logic when it doesn't have to process changes in the formatting.
  6. In the line thread.Name = "Client" + i; I would make "Client" a constant.
  7. Separate concerns. For instance: Console.WriteLine does not belong in your server class.
  8. If the constructor doesn't do anything, get rid of it, it is only adding noise to your class.
  9. In my opinion, class variables should be initialized in the constructor, not on declaration.
  10. Use meaningful names for variables: a does not portray what the variable does. tcpClient on the other hand does. This makes your methods much easier to read.
  11. getClient should be GetClient. C# naming conventions

Most of these are minor, and don't affect the application, they just add that little bit to your code, and will make it easier to read and maintain in the future.