Printing hex dump of a byte array
Thing I like less is that you're forcing caller to deal with a static method. I appreciate that kind of helpers but they should be an alternative (maybe with default settings) instead of the only way to go. Why?


If you need more parameters (or to reorder them) then you need to change all calling points.
If you add complex parameters (such as a formatter) then calling point will quickly become a mess.
They're viral. If you separate UI from underlying logic and you need to delegate some decisions to different places then you can't pass around an Hex class (where each component/control may fill its own properties) because you have a single method call.
If a static method becomes complex enough then it will also be harder to test.


I'd also change name from Hex to something that describe what your class is doing. HexStringFormatter? HexStringConverter? I'd give two alternatives:

var formatter = new HexStringFormatter();
Console.WriteLine(formatter.ConvertToString(example));


Note that in this simple case it may even be (an helper method here just save few characters, what's for?):

Console.WriteLine(new HexStringFormatter().ConvertToString(example));


A more complex case may be like this:

var formatter = new HexStringFormatter();
formatter.BytesPerLine = 32;
formatter.Content = HexStringFormatterOutput.Ascii
    | HexStringFormatterOutput.Header;


These settings may come from UI, now you can return formatter object to another method for example in charge to read data without knowing where settings come from...

Note that I also introduced an enum instead of multiple boolean properties but it's not mandatory and not even always suggested, it depends case by case (I like the enum because I can save it in one shot without any effort in my configuration files).

Also you may want to make Hex sealed, it's not intended (so far) to be extended.



You may accept IEnumerable&lt;byte&gt; instead of byte[]. Performance impact in WriteBody() with foreach is negligible, and you do not need ToArray() in your example. Not such big gain but it will let you read huge files that does not fit in memory (because you can read them block by block without need to convert to byte[] all the content).

In this regard you may want to change the output of your class. Now you need to build a huge output string, if content will be written to disk then it's a waste of resources. Write output to a TextWriter. Caller will have responsibility to give you a StringWriter if he wants to output to a string. In this case it may be nice to introduce a static helper method for the most common use case. More complex use case may be like this:

using (var output = new StringWriter())
{
    var formatter = new HexStringFormatter();
    formatter.Output = output;
    formatter.BytesPerLine = 32;

    formatter.ConvertToString(example);
    Console.WriteLine(output.ToString());
}


HOWEVER note that HexStringFormatter accepts a TextWriter and Console.Out is a TextWriter! Code will then be simplified to:

var formatter = new HexStringFormatter();
formatter.Output = Console.Out;
formatter.BytesPerLine = 32;

formatter.ConvertToString(example);


What if you need to write it to a text file?

using (var stream = new StreamWriter("path_to_file"))
{
    var formatter = new HexStringFormatter();
    formatter.Output = stream;
    formatter.BytesPerLine = 32;

    formatter.ConvertToString(example);
}


Of course you may want to introduce few helper methods for this (now they can make sense but keep them as simple as possible), something like this:

public static string DumpToString(IEnumerable&lt;byte&gt; data)
{
    using (var output = new StringWriter())
    {
        var formatter = new HexStringFormatter();
        formatter.Output = output;

        formatter.ConvertToString(data);
        return output.ToString();
    }
}

public static void DumpToFile(string path, IEnumerable&lt;byte&gt; data)
{
    using (var output = new StreamWriter(path))
    {
        var formatter = new HexStringFormatter();
        formatter.Output = output;

        formatter.ConvertToString(data);
    }
}

public static void DumpToConsole(IEnumerable&lt;byte&gt; data)
{
    var formatter = new HexStringFormatter();
    formatter.Output = Console.Out;

    formatter.ConvertToString(data);
}


Now your first example will be again like this:

HexStringFormatter.DumpToConsole(
    Enumerable.Range(0, 256).Select(x =&gt; (byte)x));




Few other minor things. Your Translate() function should be simplified and made static). Also do not need to get a new encoding for each call, use Encoding.ASCII. b &lt; 32 is clear for most of us but I'd make it explicit. For now let's keep GetString() but see later...

private static string Translate(byte b)
{
    if (IsPrintableCharacter(b))
        return Encoding.ASCII.GetString(new[] { b });

    return "."
}

private static bool IsPrintableCharacter(byte b) =&gt; b &gt; 32;


Now let's think...you're working with ASCII and byte is in range [0...255] then you may directly cast it to char (after leave to representation issues you mentioned in your Console codepage settings), you avoid to create so many strings and you do not even need any encoding:

private static char Translate(byte b)
    =&gt; IsPrintableCharacter(b) ? (char)b : '.';


Code like i &amp; 0xFF in WriteHeader() is little bit misleading, IMO. If _bytesPerLine contains an invalid value then it should throw ArgumentOutOfRangeException when you set it, it shouldn't be silently ignored. Your code will then be simplified everywhere.

About your main loop, you do not need to save _length field because you already have the input buffer. I'd also try to give names to all those ifs (=introduce bool locals or separate functions) anyway after refactoring to use IEnumerable&lt;byte&gt; it should look much simpler.