All the source code for our project is stored in Rational Clearcase. The servers are UNIX boxes. But our Clearcase clients run on Microsoft Windows boxes. As most cross platform programmers already know, the UNIX and Microsoft Windows systems have different standards as to how lines in text files are terminated. On Windows lines are terminated with a carriage return and line feed. However on UNIX lines are only terminated with a line feed.When you transfer text files between UNIX and Microsoft Windows systems, the transfer software usually takes care of these differences and converts end-of-line to the correct target platform format. Clearcase will also manage this correctly if you set it up properly. We unfortunately let each developer set up their own Clearcase client. And sometimes this is not done right. The result is that people are sometimes looking at code with the wrong termination character(s). So depending on where the files has been, you may be missing characters or see extra characters at the end of the line.
Normally what developers do on their own machine does not affect me. But when they take a file, check it out of Clearcase and mangle the text line termination, then check the resulting file back it, I encounter pain. Some developers have taken it on themselves to fix the files when they see them in Clearcase. I was forced to do this myself on some files I encountered recently. It turns out the files got mangled so there were extra line feed characters at the end of each line. The result was code that appeared as if it were formatted with double spacing. This style of code is difficult to read.
Instead of getting mad at the situation, I decided to have some fun and write a utility to strip out the extra line feeds. This made the code more readable. But then I realized that there are some instances where it is beneficial to have white space between lines. For example you normally want a blank line between different function definitions. So I had to code this logic into my little application that fixes the corrupted files. Here is the main code snippet for my application. Essentially it determines whether the previous line ended a function or class. If so, and the current line is not blank in the source file,. it will preserve the extra line with white space. Here is the code:
CString strLine;
CString strLastLine = "";
BOOL bMoreData;
bMoreData = inputFile.ReadString(strLine);
while (bMoreData)
{
// Reformat
if (!strLine.IsEmpty()
(strLastLine == "}")
(strLastLine == "};"))
{
strLine += "\n";
outputFile.WriteString(strLine);
}
strLastLine = strLine;
strLastLine.TrimLeft();
strLastLine.TrimRight();
bMoreData = inputFile.ReadString(strLine);
}
The code using Microsoft Foundation Class (MFC) classes to get the job done quickly. However the algorithm is easily understandable without knowing the specifics of MFC. I was quite pleased that the algorithm was this simple. I can't believe I even thought about fixing corrupted files by hand. We have some pretty large source files in our project. Now I am ready with my home grown reformatter program in case somebody checks in corrupted code.
