The list of problems can be
much longer than your code iself, and giving you a code sample would hardly teach you much. Instead, you should listen to some criticism, learn what you have to learn, write it again, listen to criticism, and so on. First of all, the code cannot be good or bad by itself (well, it can certainly be bad in principle, of course). It can be good a bad when the goal of it is known, as well as requirements, and this is something you did not bother to specify. So, you cannot hope for a really comprehensive advice, due to the lack of specifications.
Code is showed without the context. Where is "
ReportFolder
"?
As you use "ReportFolder" in a static method, it means that "ReportFolder" (and maybe something else is also static). This is absolutely bad. Data should not be static. Do you understand threading problems related to static and not existing for stack variables and when you use different instances of complex type in different threads? Anyway, please don't tell us you are not using threads, it won't justify the failure. There is no a reason to declare static data members. At the same time, methods are often required to be static, but then it should be methods using only the parameters and return value or object, nothing else. For instance methods, it's OK and quite appropriate to operate with their declaring type's instance members, which are accessible via "this".
File name should be a parameter of the method, not declared inside it.
Now, the fact that the
immediate constant "\\alltests.txt" is declared more then once is not a bug,
it's a crime. Do you understand that you just killed the supportability of your project? If you have to have some string constants in your code, it should be explicitly generated as
const
. Very often, constant strings belong to resource embedded in the executable module or even configuration files.
You should never use repeated concatenations like
obr_tests + '\t' + elements)
. Strings are
immutable. Do I even have to explain the implications? You should write instead:
string someContent = string.Format("{0}\t{1}", obr_tests, elements);
Your use of string looks generally very inefficient, by similar reasons.
Not a bug, but: the names like
obr_tests
violate (pretty good) Microsoft naming conventions. You should not use underscores; and never use non-common abbreviations. Use, say
someTests
(this is just a hint; instead of "some" should be something semantically sensible).
Never use "", use
string.Empty
. This is not a bug, but this will greatly help you if you start exterminating immediate constants. Search globally in most files: no "? Great! Many developers never hard-code any immediate constants but 0, 1 and null.
Your pattern of using
StreamWriter
and other stream-related types is totally wrong. (This will work, but this is actually a bug + plus code design mistake.) Think about having some exception before the stream is closed. Your use of
FileStream
is totally pointless. Should be:
string someFileName =
using (StreamWriter writer = new StreamWriter(someFileName)) {
writer.Write(buffer.ToString());
}
Please see:
http://msdn.microsoft.com/en-us/library/yh598w02.aspx[
^].
Your
textIn.Peek()
looks totally pointless. What did you want to achieve? Maybe you simply need to write all the contents at once, which is the best for more or less small files. You say that you needed to read lines and modify one. Do exactly that, than you won't need anything but
ReadLine
.
It is most likely that your
Split
calls require the option
StringSplitOptions.RemoveEmptyEntries
. Isn't likely that sometimes you may have not tab, but tabs with some accidental space characters? Such inaccurate formatting is hard to detect visually, so use:
http://msdn.microsoft.com/en-us/library/tabh47cf.aspx[
^],
http://msdn.microsoft.com/en-us/library/system.stringsplitoptions.aspx[
^].
Use FxCop:
http://en.wikipedia.org/wiki/FxCop[
^],
http://msdn.microsoft.com/en-us/library/bb429476.aspx[
^].
Break your method into smaller methods each having clear goal and simple implementation.
Right, your thinking looks convoluted, but you can train yourself. Write all intermediate steps in plain English. If you can clearly explain what they do, you can easier code them clearly. When you gain good experience, this stage won't be needed, but at first it will teach you a lot.
—SA