tag:blogger.com,1999:blog-29331675.post6751916381369741415..comments2024-03-05T17:37:00.995+01:00Comments on The Delphi Geek: When changing semantics, make sure that existing code will breakgabr42http://www.blogger.com/profile/06903558857617342477noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-29331675.post-4936942856573606462007-05-07T09:26:00.000+02:002007-05-07T09:26:00.000+02:00We usually create a new descriptive method, and ad...We usually create a new descriptive method, and add the 'deprecated' keyword to the old method to ensure current code continues to work, but you get compiler warnings as a good way to remind the programmers to update their code...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-29331675.post-52314391624301903592007-04-24T07:59:00.000+02:002007-04-24T07:59:00.000+02:00@gasper: Unit testing is fine, but it is only _uni...@gasper: Unit testing is fine, but it is only _unit_ testing. It won't help you when modified code is used in projects outside your control.<BR/><BR/>@anonymous: Yep, I also do juggle parameters around. Sometimes.gabr42https://www.blogger.com/profile/06903558857617342477noreply@blogger.comtag:blogger.com,1999:blog-29331675.post-31055403302523999452007-04-24T05:23:00.000+02:002007-04-24T05:23:00.000+02:00This is something I do all the time :) Another way...This is something I do all the time :) Another way (not applicable in your example) is to switch the parameters around.<BR/><BR/>Another thing I do all the time, which has saved my ass on countless occasions, is to put a descriptive comment with 'xxx' (or some other unique string) near code which may not be complete or hasn't been properly tested etc. Essentially it's just keeping important TODO notes but in the code itself near to where the potential issue is.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-29331675.post-50050221638496294032007-04-24T00:34:00.000+02:002007-04-24T00:34:00.000+02:00I see your point and one thing is for sure: method...I see your point and one thing is for sure: method naming should be as precise as possible so that the names clearly state the code's intention. It's actually a very common thing in refactoring (See Fowler, http://www.refactoring.com/catalog/renameMethod.html).<BR/><BR/>But, there is another thing here that helps with such situations a lot: unit testing. With that you easily spot such errors, provided you have good code coverage. In the above example, the first thing (before renaming the method) would be to change the test and only refactor the code that reports test failures.gasperhttps://www.blogger.com/profile/14376124249499800548noreply@blogger.com