Return to Answer

There is a proper place for commenting this heavily: when you're writing code that nobody will ever be an expert on and is in an unfamiliar language, or otherwise can't be understood within a reasonable amount of time.

The product I work on has about twenty-five million lines of code. Of that, about ten lines are in x86-32 assembler, and about twenty are in ARM64 assembler. Those are the only assembler code in the product. Both pieces of assembler are about creating error conditions (different ones for those two platforms) that can't be straightforwardly generated from the high level languages used in the product. This is used to test error handlers.

I wrote the x86 assembler, but I haven't needed to change it for about fifteen years. I modified the ARM64 assembler from an example last year, and have not touched it since. I won't be around forever, and nobody else in my team writes assembler. So commenting in great detail is a good idea.

There is a proper place for commenting this heavily: when you're writing code that nobody will ever be an expert on and is in an unfamiliar language, or otherwise can't be understood within a reasonable amount of time.

The product I work on has about twenty-five million lines of code. Of that, about ten lines are in x86-32 assembler, and about twenty are in ARM64 assembler. Those are the only assembler code in the product. Both pieces of assembler are about creating error conditions (different ones for those two platforms) that can't be straightforwardly generated from the high level languages used in the product. They are used in the test harness to test error handlers.

I wrote the x86 assembler, but I haven't needed to change it for about fifteen years. I modified the ARM64 assembler from an example last year, and have not touched it since. I won't be around forever, and nobody else in my team writes assembler. So commenting in great detail is a good idea.

There is a proper place for commenting this heavily: when you're writing code that nobody will ever be an expert on and cant be understood within a reasonable amount of time.

The product I work on has about twenty-five million lines of code. Of that, about ten lines are in x86-32 assembler, and about twenty are in ARM64 assembler. Both areas of assembler are about creating error conditions (different ones for those two platforms) that can't be straightforwardly generated from the high level languages used in the product. This is used to test error handlers.

I wrote the x86 assembler, but I haven't needed to change it for about fifteen years. I modified the ARM64 assembler from an example last year, and have not touched it since. I won't be around forever, and nobody else in my team writes assembler. So commenting in great detail is a good idea.

There is a proper place for commenting this heavily: when you're writing code that nobody will ever be an expert on and is in an unfamiliar language, or otherwise can't be understood within a reasonable amount of time.

The product I work on has about twenty-five million lines of code. Of that, about ten lines are in x86-32 assembler, and about twenty are in ARM64 assembler. Those are the only assembler code in the product. Both pieces of assembler are about creating error conditions (different ones for those two platforms) that can't be straightforwardly generated from the high level languages used in the product. This is used to test error handlers.

I wrote the x86 assembler, but I haven't needed to change it for about fifteen years. I modified the ARM64 assembler from an example last year, and have not touched it since. I won't be around forever, and nobody else in my team writes assembler. So commenting in great detail is a good idea.

There is a proper place for commenting this heavily: when you're writing code that nobody will ever be an expert on.

The product I work on has about twenty-five million lines of code. Of that, about ten lines are in x86-32 assembler, and about twenty are in ARM64 assembler. Both areas of assembler are about creating error conditions (different ones for those two platforms) that can't be straightforwardly generated from the high level languages used in the product. This is used to test error handlers.

I wrote the x86 assembler, but I haven't needed to change it for about fifteen years. I modified the ARM64 assembler from an example last year, and have not touched it since. I won't be around forever, and nobody else in my team writes assembler. So commenting in great detail is a good idea.

There is a proper place for commenting this heavily: when you're writing code that nobody will ever be an expert on and cant be understood within a reasonable amount of time.

The product I work on has about twenty-five million lines of code. Of that, about ten lines are in x86-32 assembler, and about twenty are in ARM64 assembler. Both areas of assembler are about creating error conditions (different ones for those two platforms) that can't be straightforwardly generated from the high level languages used in the product. This is used to test error handlers.

I wrote the x86 assembler, but I haven't needed to change it for about fifteen years. I modified the ARM64 assembler from an example last year, and have not touched it since. I won't be around forever, and nobody else in my team writes assembler. So commenting in great detail is a good idea.