Conflict Markers in Code – Justification for Leaving Them

There are no standards that exist across all industries that govern code structure. I would doubt that any industry has industry-wide coding standards that deal with comments, file structure, and project organization.

The closest thing that you might find would be MISRA C, which are guidelines produced by the Motor Industry Software Reliability Association to ensure safe, portable, and reliable code in code that runs in the embedded systems in cars. However, as I don't work in the automotive industry, I've never had to deal with this.

Typically, code structure and guidelines are done at the organizational or project level, not across organizations or within industries. If you want examples of how to write good, clean, readable code, I suggest looking at Steve McConnell's Code Complete, Andy Hunt and Dave Thomas's The Pragmatic Programmer, Diomidis Spinellis's Code Quality: The Open Source Perspective, and Robert "Uncle Bob" Martin's Clean Code: A Handbook of Agile Software Craftsmanship - these are the canonical books on how to write the best code you can, regardless of language or platform. Many languages also have style guidelines, such as Oracle's Code Conventions for the Java Programming Language, which can serve as a foundation for an organization or project's code style rules.

I come from the side that believe commits should be frequent. Exactly how frequent will depend on your personal development style. Some in the TDD world will commit every few minutes (each completed cycle), others perhaps a few times a day at what they feel to be a good point. Some benefits of frequent commits are:

• Work is backed up, useful not just in case of disk failure or some other system problem, but human issues such as leaving your laptop at home (meaning you can jump on a spare dev system if one is available) and pick up where you left off, or illness (someone else can pick up your work)
• Related to that, the ability to roll back if you realise you have gone down the wrong path at some point, without necessarily having to throw everything you have done away
• Meaningful comments with the commit will provide a development story, helping you and other team members understand the change
• Reduced likelihood of merge conflicts, as a result of using small incremental commits. Where conflicts occur, they are easier to resolve
• In a CI environment, you will be notified early of any build failures or if you have broken any tests, and can fix them while the work is still fresh and before they cause issues for other team members

Instead of branching you can use feature toggles. These can be used to keep your feature hidden on separate code paths until it is ready to be revealed. However this does introduce some complexity and extra overhead, so it's generally not worth doing this for small tasks.

I'm unclear what you mean by "if a problem is found, you can address the issue as quickly as possible". Commits are quick and cheap, you fix the bug and make another one (commit, not bug). If on the other hand you mean "oh no I've found a major problem with my feature and want to pull the whole thing from the build", feature toggling can also help in this regard, as you just switch it off.