常犯错误及各种小细节[不断更新]

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/MaxMercer/article/details/78882606
  1. strcut开数组的时候要算有几个域!!
  2. vis有的时候是bool有的时候是int, 一定要分化清楚.
  3. 注意数组可能会重定义重复使用, 一定要分开.
  4. 倍增算lca的时候要注意枚举位不要超过数组上界, 比如开了anc[x][p]第二维就枚举到那么多否则不会re, 而会进入下一维.
  5. ans开不开longlong一定要注意.
  6. windows下输出lld会炸… 除非手写auto.
  7. 注意用值域桶来计数的时候不会访问到负数去, 否则要加一个maxn来变正.
  8. 如果scc里手写栈并且用s[top+1] != u来判断的话s一定要清空 —— 所以最好老老实实写长点判, 稳.
  9. 强转longlong要注意后面不要打括号, 否则等于没有强转, 要不然就用1ll*….
  10. 数据结构题就算自己觉得稳了, 如果暴力好写的话也tm要写对拍保证正确, 不要作死不要作死不要作死啊!!!
  11. 单调指针移动来扩展/缩短区间的时候的时候要注意是应放在统计答案之前还是答案之后, 想清楚.
  12. 考试时不确定的算法或者可能不正确的贪心不要立马去写, 先回头对拍求稳, 不要作死不要作死不要作死啊!
  13. 数组赋初值的时候不要在用的过程中判0来赋, 极有可能0不是没赋值而是有意义的.
  14. 注意对拍比较输出文件也要耗时间, 不要优化无意义的常数.
  15. 至少思考过两道题再开始考虑对拍的事情.
  16. 注意题目里面可能给了好几个限制条件, 不要看漏了, 即使看完了也要在敲题前理一遍以免遗忘部分.
  17. 想出正解一定要从好几个方向验证, 自己出的样例要各种极端, 然后随机.
  18. 线段树传标记的时候是+=还是=要分清啊!! 注意赋值和增加标记下放的逻辑关系.
  19. continue时要考虑清楚有没有什么其他变量是要改变的, 否则下次循环可能会用到错误变量.
  20. 一定要检查数组每一维是否开够, 否则很容易wa(特别是有memcpy的时候).
  21. 读入char的时候要注意回车符之类的!! 不然为了保险起见还是读入%s.
  22. 平衡树之类的向下寻找都要记得pushdown!!
  23. 异或ans的时候要注意特判答案的时候(比如特判为0)ans也要赋值!!!
    想到一点写一点啦.
展开阅读全文

三层中常犯错误

10-09

rnrn相信大家对三层开发都已经耳熟能详,可是我却发现新公司的既有代码中有一些违背分层开发思想的东西,现在与大家分享这些错误,我们共勉之。rnrn如果有人觉得对三层开发拿捏得不是太准,请参照李天平的文章:分层开发思想与小笼包,这篇文章用隐喻说明分层开发,是非常好的一篇文章。rnrn正文:rnrn1.界面层参与非界面逻辑,抢业务逻辑层的饭碗rnrn什么是界面逻辑:rnrn界面层应该有的逻辑就是显示的逻辑,例如根据逻辑结果显示某一个Panel不显示另外一个Panel,或者有一个数据集应该在界面上怎么呈现,这是界面层的逻辑rnrn例子场景:rnrn用户登录时首先验证用户输入的用户名是否有效,如果用户名有效,然后再验证用户输入的密码是否和用户名匹配,如果匹配则表示用户可以登录,增加用户的登录次数,然后将用户的信息写入Session中;否则返回错误。在这个过程中除了将用户信息写入Session这一步属于界面逻辑以外其他的操作都应该放在业务逻辑层。rnrn错误代码示例:rnrnprivate void buttonLogin_Click(object sender, EventArgs ev)rnrn string userName = textBoxUserName.Text;rn string password = textPassword.Text;rnrn if (Business.Account.Exists(userName))rn rn bool success = Business.Account.Login(userName, password);rn if (success)rn rn Business.Account.AddLoginTime(userName);rnrn Session["user"] = new User(userName, password);rn Redirect("/");rn rn elsern rn this.labelMessage.Text = "登录失败。";rn rn rn elsern rn this.lableMessage.Text = "用户名不存在。";rn rnrn rnrnrn分析:在上面的代码中一个UI层的一个事件中调用了三次rules层的方法:rnrnBusiness.Account.Exists(userName)rnrnBusiness.Account.Login(userName, password)rnrnBusiness.Account.AddLoginTime(userName);rnrn还附加有条件判断,这种方法在执行效果上面是没有什么错误的,可是却造成了逻辑前移;本来应该在逻辑层执行的判断放在了界面层,是不合适的。rnrn2.数据访问层参与了大量的业务逻辑rnrn这种现象经常出现在大量使用存储过程的系统中,将一大堆逻辑统统放在一个存储过程中实现了,乍一看可能很有效率,其实造成了系统结构的失调,给维护带来困难,数据访问层甚者数据库要抢逻辑层的饭碗了。rnrn还以用户登录为例:rnrn下面是业务逻辑层的登录方法:rnrn rnrn//业务逻辑层的登录方法rnpublic int Login(string userName, string password) rnrn return DataAccess.UserAccount.Login(userName, password);rn rnrnrn rnrn下面是数据层的登录方法:rnrn rnrn//数据访问层的登录方法rnpublic int Login(string userName, string password)rn rn SqlParameter[] parameters = new SqlParameter[]rn // rn ;rn return SqlHelper.ExecuteProcedure("Login",parameters);rn rnrnrn rnrn下面是登录的存储过程:rnrn rnrnCREATE PROC Loginrn @userName varchar(20),rn @password varchar(20)rnAS rn IF NOT EXISTS(SELECT * FROM UserAccount WHERE UserName = @userName)rn RETURN -1rn IF NOT EXISTS(SELECT * FROM UserAccount WHERE UserName = @userName AND password = @password)rn RETURN 1rnrn UPDATE UserAccountrn SET LoginTimes = LoginTimes + 1rn WHERE UserName = @userNamernrn RETURN 0rn rnrnrn rnrn分析:从上面三段代码中我们可以很显然得看到登录的业务逻辑已经全部被后移到了数据库的存储过程中。这样使用的三层结构就失去了意义,逻辑层名存实亡了;而数据库的压力会越来越大;我们修改业务逻辑的时候不是到逻辑层修改,而是要到数据库中去修改了。rnrn3.将界面层上的数据组件(如SqlDataSource)作为参数传递到业务逻辑层去赋值rnrn这样做的坏处很明显,本来是界面层依赖于业务逻辑层的,现在业务逻辑层反过来去依赖界面层的类,需要逻辑层引用System.Web命名空间,显然是错误的。rnrn4.为了省事儿,不是直接将参数传递到业务逻辑层,而是通过HttpContext直接获得界面层应该传递的参数rnrn例子:在系统设计的初期没有记录用户登录的IP地址,而到了后期发现了这个问题,要求纪录用户IP了,为了不修改业务逻辑层方法的定义,也不用修改界面层的调用方法,于是便写出了下面的代码:rnrnpublic int Login(string userName, string password)rnrn string userIP = System.Web.HttpContext.Current.Request.UserHostAddress;rn //follow is login stepsrn rnrnrn这一点犯的错误和3中的错误相同,导致层之间形成了依赖环。rnrn5.将事务处理放在数据访问层来做rnrn事务处理应该放在业务逻辑层处理,原因是rnrn1)事务的划分是根据业务逻辑来定义的,通常一个事务就代表完成了一个完整的逻辑操作;rnrn2)一个业务逻辑可能有几个数据操作,修改几个表中的数据,而通常数据层的类的划分是根据数据库表来划分的,如果把事务处理放在数据访问层,那么业务层的方法需要调用两个以上的数据层方法时,就会出现执行两个事务的情况,显然这是不合理的。rnrn总结:rnrn1.在三层结构的划分中我们应该使三层各负其责,谁也不能越权,谁也不能懒惰,通常情况下,逻辑层应该在满足各负其责的条件下,尽可能的厚。rnrn2.三层结构中的依赖关系很明确,界面层依赖于逻辑层,逻辑层依赖于数据访问层,不能互相依赖,而形成依赖环。rnrnrnrn相信大家读了上的文章后,如果是做过三层的,那肯定是犯了什么的错误,怎么犯错误先不说,我先说说本人(今年毕业的学生)rn现在在公司开发项目的一点见解:rn我现在在公司开发一个商城网站,因为数据层和业务层都是我做的,所以体会还是满深的,特别是在订单处理那块,业务非常复杂rn基本要操作5个表,所以需要在业务层实现事务(关于这个我已经发了好几个帖子了),而数据层只是单纯的对某个表进行操作rn虽然.net事务能解决上面的问题,但是问题有多,或者服务器配置有问题。。。我现在想把这写操作放在数据层,那觉得有违背了三层的本意,(这样还是三层吗),所以我现在犹豫了到底要怎么做,我想大家在开发中,为了性能的提高而那样(把业务移到数据层做)做却是值得的,因为三层只是一个标准而已,并不是强制要这样做?rnrn 关于这样的错误我还想听听大家的意见?rnrn 论坛

没有更多推荐了,返回首页