Merge pull request #411 from nschonni/fix--MD038/no-space-in-code

fix: MD038/no-space-in-code

meetings/2014/LDM-2014-02-17.md

@@ -1286,7 +1286,11 @@ In C#  ```:``` is only used in _(as far I can tell)_
 both of which are contextually different so I can't see another contextual definition being a problem.
 
 This would in essence make a Dictionary Literal just a collection of Key-Value Pairs. Eg
- ```Dim myDict = { { "A" : 1 } , {"B" : 2 } , { "C" : 3 } } ```
+
+```vb
+Dim myDict = { { "A" : 1 } , {"B" : 2 } , { "C" : 3 } }
+```
+
 Is then translated into the following code.
 ```
 Dim myDict As New Dictionary(Of String, Integer)(  { ( "A" : 1 ) , ( "B" : 2 ) , ( "C" : 3 ) } 

meetings/2014/LDM-2014-10-01.md

@@ -54,7 +54,7 @@ __Out/ref arguments in C#__. Can you pass a readonly autoprop as an out/ref argu
 _Resolution: No_. For readonly autoprops passed as _ref_ arguments, that wouldn't obey the principle that access to the prop goes via its accessor. For passing readonly autoprops as _out_ arguments with the hope that it writes to the underlying field, that wouldn't obey the principle that we bind to the property rather than the backing field. For writeonly autoprops, they don't exist because they're not useful.
 
 __Static readonly autoprops__ Should everything we've written also work for static readonly autoprops?
-_Resolution: Yes._ Note there's currently a bug in the native compiler (fixed in Dev14) where the static constructor of a type G<T> is able to initialize static readonly fields in specializations of G e.g. `G<T>.x=15;. The CLR does indeed maintain separate storage locations for each static readonly fields, so `G<int>.g` and `G<string>.g` are different variables. (The native compiler's bug where the static constructor of G could assign to all of them resulted in unverifiable code).
+_Resolution: Yes._ Note there's currently a bug in the native compiler (fixed in Dev14) where the static constructor of a type G<T> is able to initialize static readonly fields in specializations of G e.g. `G<T>.x=15;`. The CLR does indeed maintain separate storage locations for each static readonly fields, so `G<int>.g` and `G<string>.g` are different variables. (The native compiler's bug where the static constructor of G could assign to all of them resulted in unverifiable code).
 
 __VB rules in initializers as well as constructors__. VB initializers are allowed to refer to other members of a class, and VB initializers are all executed during construction time. Should everything we've said about behavior in C# constructors also apply to behavior in VB initializers?
 _Resolution: Yes_.