.Net MF V4.0开源前的代码整理

简介: 已经有好长一段时间没有更新博客了,一是去美国总部和台湾出差用了不少时间,二是做.Net MF代码整理又花了近一个月的时间。不过令人欣慰的是,目前.Net MF V4.0的相关代码整理已经告一段落,就等着下一步的开源了

已经有好长一段时间没有更新博客了,一是去美国总部和台湾出差用了不少时间,二是做.Net MF代码整理又花了近一个月的时间。不过令人欣慰的是,目前.Net MF V4.0的相关代码整理已经告一段落,就等着下一步的开源了。

代码整理的目标分两部分,一是非托管代码(主要是和驱动相关的C++代码),二是托管代码(主要是.Net Micro Framework库);代码整理的步骤也分为两步,一是静态整理,目的是去除不当的注释和多余未用的代码,二是动态修改,主要更注重的是代码结构上的改进和运行性能上的提高,对非托管代码,由于没有合适的工具这步只能作罢,对托管代码就需要用Fxcop进行检测了。

Fxcop据说是个好东东,我们用的是最新的1.36版本,一检查.Net Micro Framework库,7500多个问题,哇!全部修改完估计3个月也搞不定,后来同样检测桌面版的.Net Framework V2.0的库,问题差不多,所以就放心了,看来Fxcop的规则,在微软内部来说也不是绝对的权威,不过细研究Fxcop的规则,发现真的蛮好,对提高自己的托管代码的编写质量还是有很大帮助的。

符合全部的规则是不可能的了,最后经过一番商讨,选取了如下规则(不过后来证明我们还是错了,有些规则不该加上来,不仅增加了我们的工作量,并且我们的修改,总部方面还极不满意,甚而几个主要的dll,由他们接手修改了,不过从另一个侧面可以看出,他们还是比较重视开源后的代码质量的)。

image.png

 

一、DesignRules(设计规则)

【01】、Abstract types should not have constructors(抽象类型不应具有构造函数)

【02】、Declare types in namespaces(在命名空间中声明类型)

【03】、Define accessors for attribute arguments(定义属性参数的访问器)

【04】、Do not declare protected members in sealed types(不要在密封类型中声明受保护的成员)

【05】、DoNotDeclareVirtualMembersInSealedTypes(不要在密封类型中声明虚拟成员)

【06】、DoNotHideBaseClassMethods(不要隐藏基类方法)

【07】、DoNotOverloadOperatorEqualsOnReferenceTypes(不要对引用类型重载等号运算符)

【08】、Exceptions should be public(异常应该是公共的)

【09】、Implement IDisposable correctly(正确实现 IDisposable)

【10】、Implement standard exception constructors(实现标准异常构造函数)

【11】、IndexersShouldNotBeMultidimensional(索引器不应是多维的)

【12】、MarkAttributesWithAttributeUsage(用 AttributeUsageAttribute 标记属性)

【13】、Mark enums with FlagsAttribute(用 FlagsAttribute 标记枚举)

【14】、MembersShouldNotExposeCertainConcreteTypes(成员不应公开某些具体类型)

【15】、OverloadOperatorEqualsOnOverloadingAddAndSubtract(重载加运算符和减运算符时应重载相等运算符)

【16】、PropertiesShouldNotBeWriteOnly(属性不应是只写的)

【17】、ProvideObsoleteAttributeMessage(提供 ObsoleteAttribute 消息)

【18】、ReplaceRepetitiveArgumentsWithParamsArray(用参数数组替换重复的变量)

【19】、Static holder types should be sealed(应密封静态容器类型)

【20】、Static holder types should not have constructors(静态容器类型不应具有构造函数)

【21】、StringUriOverloadsCallSystemUriOverloads(字符串 URI 重载调用 System.Uri 重载)

【22】、Types should not extend certain base types(类型不应扩展某些基类型)

【23】、Types that own disposable fields should be disposable(具有可释放字段的类型应该是可释放的)

【24】、Types that own native resources should be disposable(拥有本机资源的类型应是可释放的)

【25】、UriParametersShouldNotBeStrings(URI 参数不应为字符串)

【26】、UriPropertiesShouldNotBeStrings(URI 属性不应是字符串)

【27】、ValidateArgumentsOfPublicMethods(验证公共方法的参数)

 

二、Globalization Rules (全球化规则)

 

三、Interoperability Rules (互操作规则)

 

四、Naming Rules(命名规则)

【01】、EventsShouldNotHaveBeforeOrAfterPrefix(事件不应具有 before 或 after 前缀)

【02】、IdentifiersShouldDifferByMoreThanCase(标识符不应仅以大小写进行区分)

【03】、IdentifiersShouldHaveCorrectSuffix(标识符应具有正确的后缀)

【04】、IdentifiersShouldNotHaveIncorrectPrefix(标识符应采用正确的前缀)

【05】、IdentifiersShouldNotHaveIncorrectSuffix(标识符应采用正确的后缀)

【06】、OnlyFlagsEnumsShouldHavePluralNames(只有 FlagsAttribute 枚举应采用复数形式的名称)

【07】、Parameter names should match base declaration(参数名应与基方法中的声明保持一致)

【08】、Parameter names should not match member names(参数名不应与成员名冲突)

【09】、Type names should not match namespaces(类型名不应与命名空间冲突)

 

五、Performance Rules(性能规则)

【01】、AvoidExcessiveLocals(避免过多的局部变量)

【02】、Avoid uncalled private code(避免使用未调用的私有代码)

【03】、Avoid unused private fields(避免未使用的私有字段)

【04】、Do not cast unnecessarily(避免进行不必要的强制转换)

【05】、Do not initialize unnecessarily(避免进行不必要的初始化)

【06】、Remove empty finalizers(移除空的终结器)

【07】、RemoveUnusedLocals(移除未使用的局部变量)

【08】、Test for empty strings using string length(使用字符串长度测试是否有空字符串)

 

六、Portability Rules(可移植性规则)

 

七、Security Rules(安全规则)

【01】、Array fields should not be read only(数组字段不应为只读)

【02】、CatchNonClsCompliantExceptionsInGeneralHandlers(在常规处理程序中捕捉非 CLSCompliant 异常)

【03】、MethodSecurityShouldBeASupersetOfType(方法安全性应是类型安全性的超集)

【04】、ReviewDeclarativeSecurityOnValueTypes(检查有关值类型的声明性安全)

【05】、ReviewVisibleEventHandlers(检查可见的事件处理程序)

【06】、SealMethodsThatSatisfyPrivateInterfaces(密封满足私有接口的方法)

【07】、Secured types should not expose fields(受保护的类型不应公开字段)

【08】、StaticConstructorsShouldBePrivate(静态构造函数应为私有)

【09】、WrapVulnerableFinallyClausesInOuterTry(在外部 try 块中包装易受攻击的 finally 子句)

 

八、Usage Rules(用法规则)

【01】、AttributeStringLiteralsShouldParseCorrectly(应正确分析属性字符串文本)

【02】、Call GC.SuppressFinalize correctly(正确调用 GC.SuppressFinalize)

【03】、Collection properties should be read only(集合属性应该是只读的)

【04】、Disposable fields should be disposed(应释放可释放的字段)

【05】、DisposableTypesShouldDeclareFinalizer(可释放类型应声明终结器)

【06】、Do not call overridable methods in constructors(不要在构造函数中调用可重写的方法)

【07】、DoNotDecreaseInheritedMemberVisibility(不要降低继承成员的可见性)

【08】、Do not ignore method results(不要忽略方法结果)

【09】、Do not mark enums with FlagsAttribute(不要使用 FlagsAttribute 标记枚举)

【10】、DoNotShipUnreleasedResourceFormats(不要发行未发布的资源格式)

【11】、FinalizersShouldBeProtected(终结器应受到保护)

【12】、Finalizers should call base class finalizer(终结器应调用基类的终结器)

【13】、Initialize value type static fields inline(初始化内联值类型的静态字段)

【14】、MarkWindowsFormsEntryPointsWithStaThread(使用 STAThread 标记 Windows 窗体的入口点)

【15】、MembersShouldDifferByMoreThanReturnType(成员不应只是返回类型不同)

【16】、NonConstantFieldsShouldNotBeVisible(非常数字段不应该是可见的)

【17】、Operations should not overflow(运算不应溢出)

【18】、OperatorsShouldHaveSymmetricalOverloads(运算符应有对称重载)

【19】、PassSystemUriObjectsInsteadOfStrings(传递 System.Uri 对象而不是字符串)

【20】、TestForNaNCorrectly(正确测试 NaN)

从反馈的结果来看,应该是对我们(主要指我修改的那部分代码)删除未使用的私有变量颇有微词,看来这些变量也许是为未来升级做准备的。此外有一些地方的私有变量其存在的意义待考(总部方面似乎不愿解答这个疑问,是解答起来太繁琐?还是非常简单而近于不屑解答?未知),代码如下,开源后,也望一些深入研究的达人能告知。

public sealed class Bitmap : MarshalByRefObject, IDisposable

{

        private object m_bitmap;   <-- 这个地方搞不明白,其存在的意义是?

 

        [MethodImplAttribute(MethodImplOptions.InternalCall)]

        extern public Bitmap(int width, int height);

        [MethodImplAttribute(MethodImplOptions.InternalCall)]

        extern public Bitmap(byte[] imageData, BitmapImageType type);

        [MethodImplAttribute(MethodImplOptions.InternalCall)]

        extern public void Flush();

        ...  //余下都是Interop接口,没有什么内部函数用到m_bitmap

}

此外.Net MF的编辑器不会为没有构造函数的类,自动添加一个public的构造函数的。

从上图可以看出,.Net MF V4.0还是比3.0增加了不少dll的,新版本不仅支持Http,还支持MicroBee,更多的新功能有待我们开源后更深入地去探索。

代码开源了,授权费也不要了,目前已经有很多企业对此表示了很大兴趣,也有的企业已经直接进入了合作阶段,相信随着时间的推移和MF的不断发展,嵌入式领域的.Net征程将走的更远。

附:Fxcop下载地址

http://www.microsoft.com/downloads/details.aspx?FamilyID=9aeaa970-f281-4fb0-aba1-d59d7ed09772&displaylang=en

相关文章
|
内存技术
【玩转.Net MF – 01】Flash远程读写
目前在PC远程访问设备Flash,也就是部署TinyCLR和下载应用程序
537 0
|
内存技术
【玩转.Net MF – 02】让PC成为MF的鼠标键盘
通过扩展我以前为.Net MF开发的WinForm库(参见我以前的文章《开源System.Windows.Forms库,让.Net Micro Framework界面开发和上位机一样简单》),增加一个输入代理层,就可以实现虚拟鼠标和键盘输入。
562 0
|
网络协议
【玩转.Net MF – 03】远程文件查看器
做过WinCE或Windows Mobile开发的人都知道,VS2008开发工具提供了些远程工具,诸如远程文件查看器、远程注册表编辑器、远程堆查看器和远程放大等等。受此启发,所以才有了MF的远程文件查看器。
605 0
【玩转.Net MF – 04】远程屏幕截图
实现远程屏幕截图的思路很简单,就是直接获取设备的显存数据,由PC再现画面。由于我们已经实现了Custom信道,所以我们在原有程序基础上,增添一个Custom_Command_Screenshots命令,就可以完成数据的获取。
473 0
|
芯片 物联网 内存技术
WG7310(WLAN+Bluetooth+FM)芯片在.Net MF中的应用
WG7310芯片是Ti推出的一款芯片,集成了WLAN、Bluetooth、FM等功能(最近又推出了四合一的芯片,把GPS功能也集成了进去),由于以前在.Net MF上的一些工作是基于Ti DM335开发板上的,所以开发.Net MF系统的WiFi功能就选用了WG7310芯片。
699 0
|
芯片
免费发放firmwave,打造史上最低价.Net MF开发板
很久以前就曾多方位思考限制.Net Micro Framework发展的原因是什么?在物联网和Cortex-M3大行其道的今天,应该有更大的发展空间才对,为什么现在还是关注者甚少?我想主要原因有三,一、源码代码是否开源;二、是否有低价开发板;三、TinyCLR是否够小。
738 0
【STM32 .Net MF开发板学习-03】TinyGUI绘图示例
.Net Micro Framework官方图形库是WPF,由于目前ST Cortex-M3开发板RAM太小,最大才512K(常见是128K或256k),并且Cortex-M3的CPU主频也不太高,运行WPF图形框架显得过于重了,所以我这边推出了轻量级图形库TinyGUI
575 0
|
内存技术
【STM32 .Net MF开发板学习-04】TinyGUI位图显示
由于Cortex-M3开发板的RAM比较小,比如EM-STM3210E仅128K,所以显示位图是个比较棘手的事,如320*240 16位的位图大小就为150K,由于官方的WPF以一个BMP位图为本底进行绘图,所以RAM内存需求至少大于150K。
606 0
【STM32 .Net MF开发板学习-06】蜂鸣器和LED数码管显示
无论是蜂鸣器还是LED数码管显示,其实这二者对代码编写来说没有太大区别,都是GPIO的一个典型应用。红牛开发板有一个蜂鸣器,而EM-STM3210E有一个四位LED数码管,代码都相对简单,不值的为二者单独写一篇博文,所以二者合一以一篇文章来说明,不过两个示例代码是独立的。
630 0
|
内存技术
【STM32 .Net MF开发板学习-07】全屏位图无闪烁显示
16位320*240的位图大小为150K字节,而对于EM-STM3210E开发板来说,RAM仅有128K,远不够显示一幅完整位图,红牛的开发板即使有256K的RAM,但是刨去堆、栈及TinyCLR本身所用,剩下的也不多了,所以要显示全屏位图,必须分块显示。
510 0