When Visual Studio greys out some code and tells you it is redundant, does this mean the compiler will ignore this code or will it still compile this code? In other words, would this redundant code never be interpreted or will it be? Or does it simply act as a reminder that the code is simply not required?
If I leave redundant code in my classes/structs etc, will it have an impact on performance?
Thanks
If the code is redundant it's not necessary for compilation, but leaving it in won't have any impact on performance.
As the compiler has identified the code as redundant in Visual Studio it won't get compiled into the IL or machine code.
It's not good practice to leave redundant code in your project. If you need the code in the future you should get it from the older versions of the file in your source code repository.
C# is not an interpreted language, it's a JITted (Just-In-Time compiled) language, which means it's compiled from MSIL at runtime. Thus, the JITter can do analysis to determine whether code is redundant, and then remove it.
There will be two opportunities to remove redundant code
Compiling C# to MSIL in Visual Studio.
JITting MSIL to assembly at run (or install) time.
Because the C# compiler itself has flagged this issue, that means the code will likely be removed during (1).
So yeah, it's just being nice and reminding you. Most compilers remove redundant code in many different and subtle ways without telling the programmer, but in certain obvious cases it's a good idea to tell the programmer.
No, it's not compiled.
Can drive me nuts sometimes when testing and I want to use the debuggers "set next statement" command to some statement and it wasn't compiled.
Related
I have a question about out commented code and couldn't find a good answer.
Does the compiler read out commented code, or does it immediately skip that code?
It depends on the language.. in C++, for example, comments are processed and discarded by the preprocessor, and the compiler will not even see them.
In general, comments will not "consume memory" in the target executable. Lexers may or may not discard them right away, so they not even enter into the parsing phase of the compiler, but they do not go into the later phases of compilation.
EDIT: I have seen the C# and visual-studio tags too late...
csc: IIRC from the sscli source, comments are skipped directly by the lexer
visual studio (intellisense) it does NOT skip them immediately: it needs to process comments for coloring, regions, etc..
The compiler (like most compilers) immediately skips to the first non-commented line of code.
A notable exception are the xml comments, used for the documentation if the compiler is running with some settings.
No, it won't consume any space if you are talking about ordinary comments like // and /**/, simply because they don't any source code to be processed.
You won't find any comments in a compiled program. Have you ever tried to perform a syntax-error in a comment like
// object o = NEW object();
If the Compiler cared about this, it would have reported an error, but it won't!
Little reference here.
EDIT
There is an exception, though. If you want to transform your comments into an XML-file there is a /doc-Option for the compiler. See here.
The preprocessor, i.e. before actual compilation, the extra whitesace and comments are removed. so you don't really have to worry about the size of your code.
Also, you don't have to worry about the long names of your variables coz they're gonna be given internal names.
Could you please tell me which are the differences between rules of StyleCop and Code Analysis ? Should it be used together or not ?
Thanks.
Style cop essentially parses the file looking for formatting issues and other things that you could think of as "cosmetic". Code analysis actually builds your code and inspects the compiled runtime IL for characteristics about how it behaves when it runs and flag potential runtime problems.
So, they are complimentary, and you are perfectly fine to use them together.
Short answer:
stylecop: takes your source code as input and checks for potential code style issues. For instance: using directives are not alphabetically ordered...etc.
fxcop (now code analysis): takes a compiled assembly as input and checks for potential issues related to the executable/dll itself when it'll be executed. For instance: in your class you have a member of type IDisposable that is not disposed properly.
However, there are some rules that are common to both tools, for instance rules related to naming convention for public exposed types.
Anyway, using both is a good idea.
FxCop checks what is written. It works over the compiled assembly.
StyleCop checks how it is written. It works over the parsed source file, even without trying to compile it.
This leads to all the differences. For example, FxCop cannot check indentations, cause they are absent in a compiled assembly. And StyleCop cannot perform code-flow checks cause it doesn't know how your code is really being executed.
I've been using reflector to decompile a couple simple c# apps but I notice that though code is being decompiled, I still can't see things as they were written on VS. I think this is the way it is as the compiler replaces human instructions by machine code. However I thought I would give it a try and ask it on here. Maybe there is a decompiler that can decompile and show the coding almost identically to the original code.
That is impossible, since there are lots of ways to get the same IL from different code. For example, there is no way to know if an extension method was called fluent-style vs explicit on the declaring type. There is no way to know if LINQ vs regular code was used. All manner of implicit operations may or may not be there. Removed code may or may not have been there. Many primitives (including enums) up-to-and-including 4 bytes are indistinguishable once they are IL.
If you want the actual code, legally obtain the original code.
Existing .Net decompilers generally decompile to the best of their ability.
You appear to be asking for variable names and line formatting, which for obvious reasons are not compiled to IL.
There are several. I currently use JustDecompile found here http://www.telerik.com/products/decompiler.aspx?utm_source=twitter&utm_medium=sm&utm_campaign=ad
[Edit]
An alternative is .NET Reflector found here: http://www.reflector.net/
I believe there is a free version of it, but didn't take time to look.
Basically, no. There are often many ways to arrive at the same IL code, and there's no way at all for a decompiler to know which was used.
No, nor should there ever be. Things like comments and unreachable code would just add bloat with absolutely zero benefit. The very best you can ever do is approximate the compiled code.
In Visual Studio C/C++ projects, it's easy to modify compiler's optimization settings in "Property Pages | C/C++ | Optimization". For example, we may give different optimization levels such as /O2 and /O3, as well as advanced optimizations like "Omit Frame Pointers".
However, I can't simply find corresponding UIs in C# project of Visual Studio. All I can find is just turning off optimizations: the "Optimize code" check box is all I've got.
Can C# users control detailed compiler's optimizations like C/C++? Do I have to give compiler options in command line?
Much of the optimisation of C# code goes on at the JIT compiler level, rather than the C# compiler. Basically there are no such detailed settings as the ones available in C or C++.
There are a few performance-related elements of the runtime that can be tweaked, such as GC strategies, but not a great deal.
When I'm building benchmark tests etc from the command line I tend to just use something like this:
csc /o+ /debug- Test.cs
(I believe I have seen the presence of a matching pdb file make a difference to performance, possibly in terms of the cost of exceptions being thrown, hence the debug- switch... but I could be wrong.)
EDIT: If you want to see the difference each bit of optimization makes, there's one approach which could prove interesting:
Compile the same code with and without optimization
Use ildasm or Reflector in IL mode to see what the differences are
Apply the same changes one at a time manually (using ilasm) and measure how much each one has
AFAIK C# compiler has no such detailed optimization properties. Probably optimization is either enabled or disabled.
http://msdn.microsoft.com/en-us/library/6s2x2bzy.aspx
I found just two:
/filealign Specifies the size of sections in the output file.
/optimize Enables/disables optimizations.
A bit OT, but someone looking at this question might find this useful:
Adding this to method signature:
[MethodImpl(MethodImplOptions.NoOptimization)]
turns off compiler optimizations for that method.
See here for details:
https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396
I've just disassembled a project to debug it using Reflector, but it seems to balk at decoding the 'compile results' of automatic properties, e.g. the next line gives me a syntax error. I've tried fixing these manually, but every time I fix one, more appear.
private string <GLDescription>k__BackingField;
Is there anything I can do about this?
Ha! Stupid me: all I had to do was set the disassembler optimization in Reflector's options to .NET 3.5. Mine was on 2.0.
The compiler generates fields with "unspeakable names" - i.e. ones which are illegal in C# itself, but are valid IL.
There's no exactly accurate translation of the IL into "normal" C# (without automatic properties). You can replace < and > with _ which will give legal code, but then of course it won't be exactly the same code any more. If you're only after the ability to debug, however, that won't be a problem.
If you decompile iterators (i.e. methods using yield statements) you'll find more of the same, including the use of fault blocks, which are like finally blocks but they only run when an exception has occurred (but without catching the exception). Various other constructs generate unspeakable names too, including anonymous methods, lambda expressions and anonymous types.
On a broader note, do you have permission to decompile this code? If the author doesn't mind you doing so, they're likely to be willing to give you the source code to start with which would make your life easier. If they don't want you debugging their source code to start with, you should consider the ethical (and potentially legal) ramifications of decompiling the code. This may vary by location: consult a real lawyer for more definitive guidance.
EDIT: Having seen your own answer, that makes a lot of sense. I'll leave this here for background material.