As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Do you compile your code before committing it to the repository, even when you only change a few comments? I know comments are typically ignored by compilers, but I find myself doing this often out of habit.
It's good practice to compile the code every time prior to commit. Sometimes you accidentially edit something except the comments and thus break the code. Compiling is usually very quick and helps avoid needless pain. That's why I try to compile every time prior to commit.
I always compile before committing, the working compiled assembly should always match the working source code. In practice, you don't need to compile if you're just changing comments. But how often are comments the only thing you would change?
Remember, in .NET you can add XML comments which the compiler may read to create assembly documentation. Obviously when changing these types of comments a compile would need to be done.
I commit to git and then push my changes to an svn server everyone else uses, so I have a script that automatically rebuilds and runs tests and pushes to svn if everything passed
I can see why someone might not want to go through a compile cycle if it takes five minutes. But if that's the case, maybe you can collect all of your changes into a single compile/commit operation.
Every Commit Should Build the Mainline on an Integration Machine
e.g. in .Net, you could mess up the XML-comments and check in an unnecessary compiler warning if you are careless. So it's a good idea to compile your code every time prior to commit (as it is to run your tests before committing).
And any half decent compiler will take almost-zero time to recompile code when only comments have changed.
The first parser pass should notice that no functions have changed and stop.
From personal experience, an overworked brain has tendency to key in more than just comments and not notice it. It is probably just better to compile it even if it takes a while. Will save others the headache and protect your credibility.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a web project that I am ripping out all the inline styling and adding it to a CSS file, and I can't help but think there is an easier way to do this.
My current process is:
Search Solution for style=", if none selected, goto: 9
Cut all the text between the quote marks
Create new class in CSS file
Paste code in class
Copy class name
Return to html line and paste class name in between quote marks
Rename style to class
goto: 1
Rejoice!
I would really like to rejoice, but there seems to be a never ending supply of inline styling.
Is there a way to automate this process in Visual Studio 2010? If it requires writing a plugin, that is totally fine! I have this same task to do on many a project.
Also, I'd like to be able to do this for arbitrary tags. For example, I'm also taking all of the data-* tags and doing roughly the same thing, but adding a line of jQuery to add it back in. Something like:
$('SELECTOR').attr('data-bind','visible: IsValid');
The work is too repetitious for me not to believe there is an automated (or at least faster/better/less time consuming) way of doing this.
The project is an MVC project if that changes anything.
If you're looking for tool to replace inline style to css class, there are tools available:
http://www.voodoobytes.info/humbles-tools/
http://www.tinytool.net/96002/inline_css_extractor
You will need a macro. There are hints for realization in one file:
1/ Edit point
Dim EditPt As EditPoint
EditPt = CType(DTE.ActiveDocument.Object, EnvDTE.TextDocument).StartPoint.CreateEditPoint
2/ Searching and replacing
While EditPt.FindPattern("style="".*""")
End While
You can read text EditPt.GetText(6) (returns 'style=') delete text EditPt.Delete(6) (removes 'style=') EditPt.Insert("_") (inserts _ before 'style=').
I don't use CodeRush myself, but they seem to have what you are looking for, if this link is anything to be believed.
Move Style Attributes to External CSS
You may need to write your own plugin to do the other, but CodeRush do support this.
I was unable to find similar functionality in Resharper, although it does support plugins as well..
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
While attempting to adopt more TDD practices lately on a project I've run into to a situation regarding tests that cover future requirements which has me curious about how others are solving this problem.
Say for example I'm developing an application called SuperUberReporting and the current release is 1.4. As I'm developing features which are to be included in SuperUberReporting 1.5 I write a test for a new file export feature that will allow exporting report results to a CSV file. While writing that test it occurs to me that the feature to support exports to some other formats are slated for later versions 1.6, 1.7, and 1.9 which are documented in a issue tracking software. Now the question that I'm faced with is whether I should write up tests for these other formats or should I wait until I actually implement those features? This question hits at something a bit more fundamental about TDD which I would like to ask more broadly.
Can/should tests be written up front as soon as requirements are known or should the degree of stability of the requirements somehow determine whether a test should be written or not?
More generally, how far in advance should tests be written? Is it OK to write a test that will fail for two years until the that feature is slated to be implemented? If so then how would one organize their tests to separate tests that are required to pass versus those that are not yet required to pass? I'm currently using NUnit for a .NET project so I don't mind specifics since they may better demonstrate how to accomplish such organization.
If you're doing TDD properly, you will have a continuous integration server (something like Cruise Control or TeamCity or TFS) that builds your code and runs all your tests every time you check in. If any tests fail, the build fails.
So no, you don't go writing tests in advance. You write tests for what you're working on today, and you check in when they pass.
Failing tests are noise. If you have failing tests that you know fail, it will be much harder for you to notice that another (legitimate) failure has snuck in. If you strive to always have all your tests pass, then even one failing test is a big warning sign -- it tells you it's time to drop everything and fix that bug. But if you always say "oh, it's fine, we always have a few hundred failing tests", then when real bugs slip in, you don't notice. You're negating the primary benefit of having tests.
Besides, it's silly to write tests now for something you won't work on for years. You're delaying the stuff you should be working on now, and you're wasting work if those future features get cut.
I don't have a lot of experience with TDD (just started recently), but I think while practicing TDD, tests and actual code go together. Remember Red-Green-Refactor. So I would write just enough tests to cover my current functionality. Writing tests upfront for future requirements might not be a good idea.
Maybe someone with more experience can provide a better perspective.
Tests for future functionality can exist (I have BDD specs for things I'll implement later), but should either (a) not be run, or (b) run as non-error "pending" tests.
The system isn't expected to make them pass (yet): they're not valid tests, and should not stand as a valid indication of system functionality.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Our team is having a heated debate as to whether we allow failing unit tests to be checked-in to source control.
On one side the argument is that yes you can as long as it is temporary - to be resolved within the current sprint. Some say even that in the case of bugs that may not be corrected within the current sprint we can check-in a corresponding failing test.
The other side of the argument is that those tests, if they are checked-in must be marked with the Ignore attribute - the reasoning being that the nightly build should not serve as a TODO list for a developer.
The problem with Ignore attribute however is that we tend to forget about the tests.
Does the community have any advice for us ?
We are a team of 8 developers, with a nightly build. Personally I am trying to practice TDD but the team tends to write unit tests after the code is written
I'd say not only should you not check in new failing tests, you should disable your "10 or so long-term failing tests". Better to fix them, of course, but between having a failing build every night and having every included test passing (with some excluded) - you're better off green. As things stand now, when you change something that causes a new failure in your existing suite of tests, you're pretty likely to miss it.
Disable the failing tests and enter a ticket for each of them; that way you'll get to it. You'll feel a lot better about your automated build system, too.
I discussed this with a friend and our first comment was a recent geek&poke :) (attached)
To be more specific - all tests should be written before (sa long as it's supposed to be TDD) but those checking an unimplemented functionality should have their value prepended with negation. If it's not implemented - it shouldn't work. [If it works - the test is bad] After implementing a test you remove the ! and it works [or fails, but then it's there to do so :) ].
You shouldn't think that tests are something written once and always right. Tests can have bugs too. So editing a test should be normal.
I'd say that checking in (known) failing tests should of course be only temporary, if at all. If the build is always failing, it loses its meaning (we've been there and that's not pretty).
I guess it would be ok to check in failing tests if you found a bug and could reproduce it quickly with a test, but the offending code is not "yours" and you don't have the time/responsibility to get into it enough to fix the code. Then give a ticket to someone who knows his way around and point to the test.
Otherwise I'd say use your ticket system as a TODO list, not the build.
It depends how you use tests. In my group, running tests is what you do before a commit in order to check that you (likely) have not broken anything.
When you are about to commit, it is painful to find failed tests that seem vaguely possibly related to your changes but still strange, investigate for a couple of hours, then realize it cannot possibly be because of your changes, do a clean checkout, compile, and find that indeed the test failures come from the trunk.
Obviously you do not use tests in the same way, otherwise you wouldn't even be asking.
If you were using a DVCS (e.g., git) this wouldn't be an issue as you'd commit the failing test to your local repository, make it work, and then push the whole lot (test and fix) back to the team's master repository. Job done, everyone happy.
As it seems you can't do that, the best you can do is to first make sure that the test is written and fails in your sandbox, and then fix that before committing. This might or might not be great TDD, but it's a reasonable compromise with the working practices of everyone else; working with your co-workers is more important than following some ivory tower principle in every aspect, since the author of the principle isn't located in the cubicle next door…
The purpose of your nightly build is to give you confidence that the code written the day before hasn't broken anything. If tests are often failing then you can't have that confidence.
You should first fix any failing tests you can and delete or comment out/ignore the other failing ones. Every nightly build should be green. If its not then there is a problem and that's immediately obvious now since it should have run green.
Secondly, you should never check in failing tests. You should never knowingly break the build. Ever. It causes unnecessary noise, distractions and lowers confidence. It also creates an atmosphere of laziness around quality and discipline. With respect to ignored tests which are checked in, these should be caught and addressed in your code reviews, which should be covering you test code as well.
If people want to write their code first and tests later, this is OK (though I prefer TDD), but only tested code which runs green should be checked in.
Finally, I would recommend changing the nightly build to a continuous integration build (run on each code check in) which might just change people's habits around code check-in.
I can see that you have a number of problems.
1) You are writing failing tests.
This is great! However, someone is intending to check those in "to be fixed within the current sprint". This tells me that it's taking too long to make those unit tests pass. Either the tests are covering more than one or two aspects of behaviour, or your underlying code is far too complex. Refactor the code to break it up and use mocks to separate the responsibilities of the class under test from its collaborators.
2) You tend to forget about tests with [Ignore] attributes.
If you're delivering code that people care about, either it works, or it has bugs which require the behaviour of the system to be changed. If your unit tests describe that behaviour but the behaviour doesn't work yet, then you won't forget because someone will have registered a bug. However, see point 1).
3) Your team is writing tests after the code is written.
This is fairly common for teams learning TDD. They might find it easier if they thought of the tests not as tests to check if their code is broken, but examples of how another developer might want to use their code, with a description of the value that their code provides. Perhaps you could pair with them and help them learn from what they already know about writing tests afterwards?
4) You're trying to practice TDD.
Do or do not. There is no try. Write a test first, or don't. Learning never stops even when you think you're doing TDD well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When I started building a continuous integration server, I ran across the statement "It's bad to break the build [of the code]." After finishing that project I came to the conclusion that
"Breaking the build." was a catchy phrase that was being thrown around a lot because of the alliteration, or
I wasn't understanding a key element of Continuous Integration.
So my question is in the spirit of #2: why is breaking the build a bad thing?
Be very careful in labeling "Breaking the Build" as a bad thing. It is something that needs immediate attention, but it is also a very normal and expected part of the development cycle. This is why Continuous Integration is so useful -- it tells you immediately when the build is broken, and what change set caused it. It helps you get back on track quickly.
If your culture penalizes "Breaking the Build", then you are in danger of cultivating a toxic work environment. Again, consider it to be something that needs immediate attention, but don't label it as "bad".
Because if other people check out your broken changes, they won't be able to work, or if they do they will do so less efficiently.
It also means you're not properly testing your changes before you commit, which is key in CI.
From Martin Fowler http://martinfowler.com/articles/continuousIntegration.html
The whole point of working with CI is
that you're always developing on a
known stable base. It's not a bad
thing for the mainline build to break,
although if it's happening all the
time it suggests people aren't being
careful enough about updating and
building locally before a commit. When
the mainline build does break,
however, it's important that it gets
fixed fast.
Because if other people checkout the changes, they won´t be able to work...
This image is copyrighted to Geek & Poke under a Creative Commons License
It you break the build as has happend to me yesterday. When your team-mates try and use the sourcecode. It will not build. Therfore they will struggle to test the work that they are doing. It get worse the bigger your team.
Surely the whole point of continuous integration is to identify problems early. Daily or more frequent check ins are required to reduce conflicts to a manageable size.
You should get an up to date copy of the repository and build locally. This will tell you if your proposed check in will break the build. You resolve any issues and then check in.
In this way the integration issues are kept local and easy to fix.
Breaking the build has dire implications for the project schedule (and the blood pressure of team-mates)
=> Other developers who then get latest version can no longer build there own changes, delaying them
=> Continuous integration will break, meaning that formal testing can be delayed
Many version control tools (e.g. TFS) can prevent developers from checking in code which does not compile or pass unit or code analysis tests.
Once builds start breaking, people get reluctant to get the latest changes, and you begin the deadly spiral towards Big Bang integration of changes.
I don't think breaking the build is necessarily a bad thing, as long as there is a well-known, working branch or tag in the repository. That said, make your own branch in the repository if you know your code is going the break the build today, but you will fix it next week. Then later you can merge back into trunk.
Because it means someone has done something bad (or at least, some changes have clashed) and you can no longer build and deploy your system.
Breaking the build means that you committed code to a shared repository that either (a) does not compile, or (b) does not work (fails unit tests). Anyone else who's developing from that shared repository is going to have to deal with the broken code you committed until it is fixed. That will cause a loss of productivity for the entire team.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Having the best forum website among developers, I think I will find a very good consensus of what policies and best practices make good coding. I will put some of them here, so I give the idea, but I will like to hear your opinion and the votes will probably be the judge of the best policies around.
Specific Indentation for coding between development teams
Specific comments before each method, before each variable declaration
Naming conventions, camel case or any other.
In HTML commenting after each container tag.
In CSS, using each declaration only once.
You get the idea. I will like to know what things company ask us to do, and what of those really work to obtain maintainable and beautiful code.
I would focus any policies around development practices rather than code formatting. Some examples are:
Always use parameterized SQL queries. Never concatenate user input into a query.
Keep HTML, CSS and JavaScript in separate files.
Use jslint or an equivalent tool every time you commit code.
Pick an HTML standard (such as HTML 4.01 strict). All HTML must validate.
And don’t be a policy-nazi. Sometimes rules have to be broken—but there should be a very good reason for doing so.
Code doesn't exist if it's not under version control. More specifically, NOTHING is on a production server unless it's committed to the repository.
If a project presents an opportunity to refactor old code, take that opportunity.
Maintain a wiki or similar to document procedures, standards and use of library code (when such documentation is too much for code comments)
(For PHP projects, at least -- note that PHP is open-source and has an important community ; so, many things are quite driven by what's done in the community)
First of all, when using a Framework on a project (ie, always), we try to stick to its policy, if clearly defined (it's the case for Zend Framework, at least) : it ensures anyone who will come to work on this project can :
find a definition of the standard
re-use it on any other projects that use the same framework
even when going to another company, or working for another client
or when coming from another company ;-)
Considering we are only using between 3 and 5 frameworks for PHP projects in the company I work for, and that many rules defined in their standards are the same, it's not a real problem.
Same applies if coding inside/arround some kind of CMS, for instance, of course.
When not using a specific framework, we try to stick to a common set of rules widely accepted amongst the PHP community : same way, it ensure those rules are well-known (even by new-comers to our company), easy to find, and that many people did try them and enhanced them.
About comments, there is one tool that is well-used in PHP : phpDocumentor (about the same thing as javadoc) ; it defines a standard -- this one is the de-facto standard, as there is no other tool that is used that much.
About specific comment-tags :
we always use #param / #return : they are integrated in the IDE, to provide type-hinting, so are useful
else, we don't use much : a couple of lines to say what the method does if it's not obvious ; a couple of lines if a difficult algorithm is used.
Camel-case or other : we stick to what is common amongst both the PHP community and frameworks :
this_is_a_function
And
ThisIsAClassName
And
thisIsAMethodName
In HTML : as much as possible, we don't use HTML comments, because they are sent to the browser :
means bigger pages (ok, not that much)
means giving away informations the user doesn't need
If possible, we use comments from the templating-engine.
In CSS : we comment when needed ; more important thing is to use several small CSS files, quite specific (even if using a merge-tool during the build process)
But, maybe more important than all this : we try to use "clean" code, with small methods that only do a small "unit" thing, with self-describing names and all
It doesn't do magic, but it helps understanding the code... And, also, testing it, re-using it, ...
Also, as Nate said : these are mostly guidelines -- except if specifically required by a client... In which case you have to put some automatic tool (In your build process, for instance) to verify they are followed by the letter.