I recently submitted an answer to a code-golf question in VB.NET, and one comment pointed out that I could omit two System. statements from the code, because it would compile fine without them.
See here: http://codegolf.stackexchange.com/a/63945/20520 https://codegolf.stackexchange.com/a/63945/20520
The problem here is, that the code would not be correct without them in my opinion. What happens is, that the project file advises MSBuild to automatically import the System namespace.
To avoid cheating I compile the code using the VB codedom compiler, as I figured that this is the most raw form of compiling VB.NET. I find that too much stuff goes on in the background when you compile directly from Visual Studio.
This poses the question: How should one rate VB.NET code? As MSBuild is the default compilation method and it works without the System. statements, should the code be considered correct if it works with a project file and MSBuild? Or should one strife to avoid any little helpers?
This goes a bit into the direction of compiler flags, but is more specific to the .NET languages, in particular to VB.NET.
To make it a bit broader:
In the case of the imports or references, these are included in the project file (.csproj or .vbproj) like this
<Reference Include="System" />
...
<Import Include="System" />
As Martin has pointed out in the comments, compiler specific answers don't need to include the flags in the byte code, but non-standard content - and I would say the project files are never standard - need to count. But in no answer I can find are the project files included in the score. Where is the line to draw here?
I recently submitted an answer to a code-golf question in VB.NET, and one comment pointed out that I could omit two System. statements from the code, because it would compile fine without them.
See here: http://codegolf.stackexchange.com/a/63945/20520
The problem here is, that the code would not be correct without them in my opinion. What happens is, that the project file advises MSBuild to automatically import the System namespace.
To avoid cheating I compile the code using the VB codedom compiler, as I figured that this is the most raw form of compiling VB.NET. I find that too much stuff goes on in the background when you compile directly from Visual Studio.
This poses the question: How should one rate VB.NET code? As MSBuild is the default compilation method and it works without the System. statements, should the code be considered correct if it works with a project file and MSBuild? Or should one strife to avoid any little helpers?
This goes a bit into the direction of compiler flags, but is more specific to the .NET languages, in particular to VB.NET.
To make it a bit broader:
In the case of the imports or references, these are included in the project file (.csproj or .vbproj) like this
<Reference Include="System" />
...
<Import Include="System" />
As Martin has pointed out in the comments, compiler specific answers don't need to include the flags in the byte code, but non-standard content - and I would say the project files are never standard - need to count. But in no answer I can find are the project files included in the score. Where is the line to draw here?
I recently submitted an answer to a code-golf question in VB.NET, and one comment pointed out that I could omit two System. statements from the code, because it would compile fine without them.
See here: https://codegolf.stackexchange.com/a/63945/20520
The problem here is, that the code would not be correct without them in my opinion. What happens is, that the project file advises MSBuild to automatically import the System namespace.
To avoid cheating I compile the code using the VB codedom compiler, as I figured that this is the most raw form of compiling VB.NET. I find that too much stuff goes on in the background when you compile directly from Visual Studio.
This poses the question: How should one rate VB.NET code? As MSBuild is the default compilation method and it works without the System. statements, should the code be considered correct if it works with a project file and MSBuild? Or should one strife to avoid any little helpers?
This goes a bit into the direction of compiler flags, but is more specific to the .NET languages, in particular to VB.NET.
To make it a bit broader:
In the case of the imports or references, these are included in the project file (.csproj or .vbproj) like this
<Reference Include="System" />
...
<Import Include="System" />
As Martin has pointed out in the comments, compiler specific answers don't need to include the flags in the byte code, but non-standard content - and I would say the project files are never standard - need to count. But in no answer I can find are the project files included in the score. Where is the line to draw here?
I recently submitted an answer to a code-golf question in VB.NET, and one comment pointed out that I could omit two System. statements from the code, because it would compile fine without them.
See here: http://codegolf.stackexchange.com/a/63945/20520
The problem here is, that the code would not be correct without them in my opinion. What happens is, that the project file advises MSBuild to automatically import the System namespace.
To avoid cheating I compile the code using the VB codedom compiler, as I figured that this is the most raw form of compiling VB.NET. I find that too much stuff goes on in the background when you compile directly from Visual Studio.
This poses the question: How should one rate VB.NET code? As MSBuild is the default compilation method and it works without the System. statements, should the code be considered correct if it works with a project file and MSBuild? Or should one strife to avoid any little helpers?
This goes a bit into the direction of compiler flags compiler flags, but is more specific to the .NET languages, in particular to VB.NET.
To make it a bit broader:
In the case of the imports or references, these are included in the project file (.csproj or .vbproj) like this
<Reference Include="System" />
...
<Import Include="System" />
As Martin has pointed out in the comments, compiler specific answers don't need to include the flags in the byte code, but non-standard content - and I would say the project files are never standard - need to count. But in no answer I can find are the project files included in the score. Where is the line to draw here?
I recently submitted an answer to a code-golf question in VB.NET, and one comment pointed out that I could omit two System. statements from the code, because it would compile fine without them.
See here: http://codegolf.stackexchange.com/a/63945/20520
The problem here is, that the code would not be correct without them in my opinion. What happens is, that the project file advises MSBuild to automatically import the System namespace.
To avoid cheating I compile the code using the VB codedom compiler, as I figured that this is the most raw form of compiling VB.NET. I find that too much stuff goes on in the background when you compile directly from Visual Studio.
This poses the question: How should one rate VB.NET code? As MSBuild is the default compilation method and it works without the System. statements, should the code be considered correct if it works with a project file and MSBuild? Or should one strife to avoid any little helpers?
This goes a bit into the direction of compiler flags, but is more specific to the .NET languages, in particular to VB.NET.
To make it a bit broader:
In the case of the imports or references, these are included in the project file (.csproj or .vbproj) like this
<Reference Include="System" />
...
<Import Include="System" />
As Martin has pointed out in the comments, compiler specific answers don't need to include the flags in the byte code, but non-standard content - and I would say the project files are never standard - need to count. But in no answer I can find are the project files included in the score. Where is the line to draw here?
I recently submitted an answer to a code-golf question in VB.NET, and one comment pointed out that I could omit two System. statements from the code, because it would compile fine without them.
See here: http://codegolf.stackexchange.com/a/63945/20520
The problem here is, that the code would not be correct without them in my opinion. What happens is, that the project file advises MSBuild to automatically import the System namespace.
To avoid cheating I compile the code using the VB codedom compiler, as I figured that this is the most raw form of compiling VB.NET. I find that too much stuff goes on in the background when you compile directly from Visual Studio.
This poses the question: How should one rate VB.NET code? As MSBuild is the default compilation method and it works without the System. statements, should the code be considered correct if it works with a project file and MSBuild? Or should one strife to avoid any little helpers?
This goes a bit into the direction of compiler flags, but is more specific to the .NET languages, in particular to VB.NET.
To make it a bit broader:
In the case of the imports or references, these are included in the project file (.csproj or .vbproj) like this
<Reference Include="System" />
...
<Import Include="System" />
As Martin has pointed out in the comments, compiler specific answers don't need to include the flags in the byte code, but non-standard content - and I would say the project files are never standard - need to count. But in no answer I can find are the project files included in the score. Where is the line to draw here?