As far as development (and your direct question) goes, this can't be an anti-pattern as log file content isn't a programming pattern to begin with.
Doing it your way
The main problem with the dashlines you're using is that log writers will be competing with one another.
How are you going to handle nested lines? They should increment in size, but how do you expect the inner logic to be aware of how deep it is situated? How are you going to handle a single piece of logic that for log file A is on the second nesting level, but for log file B is on the fourth nesting level?
You're going to end up tightly coupling your code as each module needs to know where it fits in the big scheme of things; which inherently breaks your encapsulation among other things.
If you want to do this, you're going to have to create a logging class that can handle indentation. A basic example:
public class IndentedLogger
private readonly string filepath;
private readonly string indentationSegment;
private readonly int indentationLevel;
private readonly string indentationLine;
public IndentedLogger(string filePath, string indentationSegment, int indentationlevel = 1)
this.filePath = filepath;
this.indentationSegment = indentationSegment;
this.indentationLevel = indentationLevel;
var sb = new StringBuilder();
for(int i = 0; i < indentationLevel; i++)
this.indentationLine = sb.ToString();
public void WriteMessage(string message)
public void WriteIndentedMessage(string message)
public IndentedLogger Next()
return new IndentedLogger(
this.indentationLevel + 1);
You can then use this logger to "pass down" to all methods where needed:
Layer1(new IndentedLogger(@"C:\test.txt", "----"));
public void Layer1(IndentedLogger log)
public void Layer2(IndentedLogger log)
public void Layer3(IndentedLogger log)
Which will give you the following output:
However, were Layer3 to be called directly by Layer1, you would get:
Which means that your indentation changes based on how deep into the nested logic you are.
At this point, you can use whatever style you want. But the necessity of having a custom class tailored to do what you want should be clear.
Doing it another way
The one big problem I have with your approach is that you end up choosing what is important to you. However, some log files contain a varied type of information. Sometimes (e.g when hunting a bug) you want to see lines A,B,C, but other times (e.g. when tracking performance) you want to see lines A,C,E.
What you're doing now is deciding a single way of how you want to view the data.
A better approach would be to post-process the log file based on what you want. For example, you can add an identifier to each log line; which you can later use to find relevant lines. If you're using excel, you can apply color coding to the log based on the type found in the line.
Identifiers could be just about any arbitrarily chosen string. "CREATE_USER", "ERROR", "PERFORMANCE", ... or you could use the more standard log levels: Fatal/Error/Warning/Info/Debug/Trace. I can't answer this for you, pick whichever identifier seems best and unambiguous.
This makes it possible for you to highlight the log messages of type A,B,C and for your colleague to highlight the log messages of type A,C,E. You simply have to use different Excel formatting rules, but the log remains the same.