Tag: C#
今天在看代码修改记录的时候发现有这么一处改动, 虽然这个改动已经很久了,但是我觉得有必要拿出来大家讨论一下: 2007年 .NET 3.5 之后推出LINQ,其实整个函数只是在做一件事,就是返回类成员 layoutList 中是 LayoutDevice (后面改成LayoutAnt )的列表.但实际上这通过 C#的LINQ只需要用 OfType<LayOutDevice> 或者 OfType<LayOutAnt> 即可(暂且不说改动包括重构类型) 左边的版本实际上是OK的,这就是学校的标教科书版本,无可厚非,但右边的这个版本就大有问题,因为参数含有引用 ref, 也就是说每次都把外面传进的变量给清空了,这种函数拿来单元测试并不友好. 如果一定要重新造轮子,两个版本都有小问题,一个是 private 方法不好单元测试,另一个是都使用了成员变量 layoutList, 最好是改成 public static 公有静态方法,传入 layoutList, 然后像第一种方式返回新的List.这样的话,这个公有静态方法就是不会更改 …
计算圆周率是个老掉牙的课题. 最为简单的 直接易懂的无非就是通过 Monte Carlo 来随机撒点 然后 计算 在圆内的点和总共的点数的比例再乘于4就能得到一个估计的值. 当然随机数的产生一定要质量好 虽然计算机没有真正的随机算法 但是一些 伪随机 算法 比如 xorshift 就很不错. 单机版本的计算 简单明了. int monte_carlo_count_pi(int n) { int c = 0; for (int …
现在的编译器已经非常强大, 在大多数情况下, 开发者无需手动进行底层代码优化. 正如计算机科学家 Donald Knuth 所说: “过早优化是万恶之源”. Pre-optimisation is the root of evil. 过早关注细节优化, 反而可能导致代码复杂度增加, 降低可读性和可维护性. 与其过度纠结于微小的性能提升, 不如专注于编写清晰/可扩展的代码, 并在真正的性能瓶颈显现后, 基于数据进行针对性的优化. 现代软件开发更强调架构设计/算法选择和合理的数据结构, 这些往往比局部优化更能带来实质性的性能提升. 以下测试是基于: Benchmark. 计算PI的程序在这里能找到 源代码. 测试机器的性能配置如下: 16GB …
几乎所有软件程序都能被破解, 只是时间长短的问题, 国外有一个有名的组织是 ZeroDay 意思就是不用一天就可以破解任何软件. 有两种桌面程序,最常见的就是用 C++/Delphi 编写的 原生 native 代码,这样写出来的软件是不容易看到源代码的,因为编译器做了优化和处理.这样的代码的优点是执行速度快,效率高, 但是关键部分的代码,比如 License 验证,有经验的黑客还是很容易破解的. 俄罗斯有一个很有名的商业软件 VMProtect, 用于保护 native 代码,保护强度非常不错, 加壳,压缩,虚拟指令,防虚拟器,防调试程序等功能,保护出来的文件有时候会被一些杀毒软件认为是恶意的程序.因为用到了一些特殊指令,而杀毒软件无法分析.这种情况下可以通过联系杀毒软件公司将程序加入白名单里. .NET 程序是另一大类别.有点和 Java 类似, .NET 程序编译出来不是 本地代码 (Native),而是中间代码(类似JAVA的 ByteCode). …
.NET 4.0 之后 (e.g. 4.5) 添加了并行 For, ForEach 的支持.如果你的代码里有很多处 SIMD (单指令,多数据 Single Instruction Multiple Data). 就可以通过 Parallel.For 和 Parallel.ForEach 来进行多线程.使用方法非常简单:你不需要再手动创建几个线程,然后同时启动多线程,并等待它们的执行(同步). 首先,你需要引用这两个单元. using System.Threading; using System.Threading.Tasks; 为了演示方便,建立了一个长度为10的数组,元素是 Double 类型. double …
在做代码审核的时候,发现有一同事写了这样的代码.出现这种代码只能说明工作压力山大, 都不思考了. 不需要注释也能看明白,意思就是想获取一个唯一的临时文件,用了 Path.GetRandomFileName() 得到一个随机文件名,并且用 Path.GetTempPath() 得到临时文件夹.问题是他觉得这样不保险,于是就不停的尝试,如果文件存在的话,就试着下一个随机的文件名,直到不重复(或者最大尝试 100 次), 看到这里, 真是醉了. 另一个小问题就是,这个 while 还每次判断 文件名是否为空,这个只有在第一次判断的时候才为空,之后都不可能为空的,这样的代码质量真的很低. C# (.NET) 里 Path.GetTempFileName() 创建一个临时文件,并返回这个文件名.创建文件名的好处是这样就能确定该文件是唯一的, 因为其它进程在执行这个函数的时候如果文件名存在,则会获取下一个临时文件名并创建.每次都能保证唯一,而不会出现多个进程获取得到同样的文件名. 该程序员想的是,获取一个文件名(并不着急创建),之后再创建,感觉就是脱裤子放屁,多此一举,因为获取临时文件名就是肯定要创建该文件的,不创建的话获取文件名干什么? 代码审核很重要,因为这段代码平常来说是不会出问题的,但是效率实在不敢恭唯. 实际上,上面的代码完全可以替换成下面的代码(不会创建文件名), 这样的结合会更加实用些 (而且更简便, 高效) public static …
