I wish there were more ways to define new code.For example, through a git or svn version, or after a specified date;
Inspection may not always be performed directly when our warehouse branches are opened; Later checks need to be baselined. One way to do this is to fall back to the branch, but the version you fall back to may not be able to compile successfully, which can lead to some errors. For some reason, we can’t use the reference branch to set the new code cycle. Our branch is checkout from the master branch, but commits the code once, and this commit is the actual baseline code. Do you have any good strategy suggestions?
Analysis assumes compiled & runnable code. For some languages that’s explicit: Java analysis requires the class files, and C, C++, Objective-C and C# analysis require participation in the build. For other languages, it’s implicit but it’s there. That’s why we generally don’t have rules for things that would render interpreted code unrunnable.
So at this point, I want to back up a bit. The baseline for New Code calculation should always be a “last, good point”. Historically, it was the last version / build / analysis deployed to production. Wanting to set an uncompilable version as the New Code baseline is antithetical to good Clean as You Code practices.
That said, you do have the option to use the Web API to set the baseline to a specific analysis. But again, that assumes that the baseline has previously been analyzed (which assumes compiled / compilable code).