C#程序中注释过多的8条理由
作者:网络转载 发布时间:[ 2013/6/20 10:55:24 ] 推荐标签:
程序中中的注释,一般是有益处的,可以知晓程序的一些逻辑说明,或是参数解释。但是有些程序,因为注释太多,反而引起维护上的不方便,删掉了怕以后不能出现问题不好查找原因,不删除留在代码中,对程序的维护人员,是一种痛苦。
以下列举我可以理解的的原因,供分析参考。
1、方法调用移动到新的类型中,原方法仍然保留在原来的类型中
//public void ExecuteSqlCommand(string sqlCommandText)
//{
//this.ExecuteSqlCommand(sqlCommandText, CommandType.Text, null);
//}
......
ExecuteSqlCommand方法已经被移植到新的辅助类型SqlHelper中,但是这里的还没有直接删除。保留的目的,有可能存在反射调用,在报错之后,看到这里的代码被注释后,再才会重新查找这片代码的新的归属。
2、删除不需要考虑的的条件或情况,因为怕考虑不充分而没有删除代码
static ClientProxyFactory()
{
_managerTypeAssemblies = new List<string>();
_managerTypesCache = new Dictionary<string, Type>();
_managerInstancesCache = new Dictionary<string, IManagerBase>();
EnableManagerInstanceCache = true;
//if (Platform == CommunicationPlatform.Local)
//{
// foreach (string file in ManagerAssembly)
// {
// if (File.Exists(String.Format("{0}.dll", file)))
// {
// Assembly assembly = Assembly.Load(file);
// _managerTypeAssemblies.Add(assembly);
// }
// }
//}
}
......
在上面的代码中,CommunicationPlatform为Local的情况被注释掉了,但是没有直接删除。被注释的代码的作用是添加程序集到_managerTypeAssemblies类型中。可能是的原因是,系统现在不再支持Local模式,而只支持.net Remoting模式,所以这段代码会被注释。
3、因为考虑不周全,导致代码中注释与功能并存。保留注释是为了出错的情况下,帮助分析代码
来看下面的二个公共方法的定义,一个是反射调用静态方法,另一个是反射调用静态属性的值。
/// <summary>
/// 静态方法的调用
/// </summary>
/// <param name="file"></param>
/// <param name="typeName"></param>
/// <param name="methodName"></param>
/// <returns></returns>
public static object InvokeStaticMethod(Type typeName,string methodName,object [] args)
{
//Assembly assembly = Assembly.LoadFile(file);
//Type type = assembly.GetType(typeName);
Assembly assembly = typeName.Assembly;
//obj2 = Activator.CreateInstance(type, args);
System.Reflection.MethodInfo method = typeName.GetMethod(methodName,new Type[]{ typeof(object)});
// object obj= assembly.CreateInstance(typeName);
// object obj = Activator.CreateInstance(typeName, args);
return typeName.InvokeMember(methodName, BindingFlags.Public | BindingFlags.Static, null, null, args);
}
public static object GetStaticPropertyValue(Type type, string propertyName)
{
object objec=CreateObjectInstance(type);
PropertyInfo propertyInfo = type.GetProperty(propertyName,BindingFlags.Public | BindingFlags.Static | BindingFlags.DeclaredOnly);
//type.GetProperty(propertyName).GetValue(null, null);
return propertyInfo.GetValue(objec, null);
}
从上面被注释的代码中可以看到,需要的代码与被注释的代码共同存在。可能因为参数或是条件的不同,被注释的代码可以运行,是正确的,但是当前情况下,没有被注释的代码才可以运行。公共框架的开发本身要考虑的条件很多,测试也要充分才能保证无错。从这里也可以看出,反射给代码重构带来障碍,因为不知道代码在哪里会被反射调用,所以代码只有等到运行出错之后才发现。
除非正常调用情况下无法实现,应该减少反射调用代码。或者对反射调用代码进行封装,所有的反射调用放在一个ReflectionHelper类型中,如果要查找问题,只需要在这个类型的相应方法中打断点即可。
4、异常处理机制的改变,导致代码中捕获异常的代码被注释
请看下面的二个方法,用于拷贝文件和拷贝目录
//bakup file
public static BackupFile(string sourceFileName, string destFileName)
{
try
{
System.IO.File.Copy(sourceFileName, destFileName, true);
return true;
}
catch (Exception e)
{
throw e;
}
}
public static void CopyDirectory(string oldDir, string newDir)
{
try
{
DirectoryInfo dInfo = new DirectoryInfo(oldDir);
CopyDirInfo(dInfo, oldDir, newDir);
}
catch (Exception exc)
{
throw new Exception(exc.ToString());
}
}
这种依靠返回true/false的得知代码是否执行成功。我现在比较反感这样的代码。因为如果拷贝文件或拷贝目录出错,没有报错,异常在这里被捕获。而且第二个方法CopyDirectory中,抛出异常后会改变异常的堆栈信息,这样导致比较难发现错误。如果是WinForms程序,应该以下面的方式处理异常
CustomExceptionHandler eh = new CustomExceptionHandler();
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CustomExceptionHandler.CurrentDomain_UnhandledException);
Application.ThreadException += new ThreadExceptionEventHandler(eh.OnThreadException);
在程序的入口处,设置UnhandledException 和ThreadException 的处理情况,程序中有发生异常后,流程会跳转到这里,作统一的处理。以我的实践,像下面这样的方法,不应该这样处理
/// <summary>
/// 复制文件,如果目标文件已经存在则覆盖掉
/// </summary>
/// <param name="oldFile">源文件</param>
/// <param name="newFile">目标文件</param>
public static void CopyFile(string oldFile, string newFile)
{
try
{
File.Copy(oldFile, newFile, true);
}
catch (Exception exc)
{
throw new Exception(exc.ToString());
}
}
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11