Identifier,Sentence,Rule
Ind_4,"They should always be documented","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
Ind_4,"No but a question should be: when you should document delayed/intended work, how frequently do you insert comments? I would say about 50-75% of the time, it should be 100% of course.","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
Ind_19,"Inline comments on the code are only needed if the code is complex and if it's not immediately obvious what the code does.","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
OSS_6,"No, but we typically do TODO annotations. This is for the readers of the source code so that they are not confused.","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
OSS_13,"Visual studio has TODO and HACK functionality build in, so I do use both.","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
OSS_19,"Only simplistic ones: use capitals in TODO/FIXME (we use both) and use // comments for these (not /*).","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
OSS_40,"ad-hoc todo code comments","ALWAYS DOCUMENT TD AS SOURCE CODE COMMENTS"
Ind_6,"TODO is for small-ish tasks or document the intend way to do a bigger work like a refactor that must be referenced as an issue number in the TODO comment.","LINK TO ISSUE TRACKER"
Ind_19,"""Policy that I tend to use is the following:IDEA: a (not-validated) thought for further improvement of the code (with better performance or better design), something worth exploring in the future TODO: the code works and can be used in production, but the todo indicates something that should be done given enough time to clean up or improve the code""","LINK TO ISSUE TRACKER"
Ind_21,"Yes we do: no TODO's without names or initials of the engineer. Only use TODO's if you really have to and if you do explain in comment what to do and when (e.g. when user story xxx goes to production, remove this end-point). The code is scanned by Sonar and warns you that you're committing a todo. You have to justify the existence of the TODO's to code reviewers.","LINK TO ISSUE TRACKER"
Ind_23,"it is expected to attach a name to a TODO so that it is visible from code without git-blaming who is supposed to work on what","LINK TO ISSUE TRACKER"
Ind_24,"There are policies of tracesbility of known issues. Breakpoints, comments and other referrals annotating bugs, planned work or a temporary fix are widely used.","LINK TO ISSUE TRACKER"
Ind_34,"Nothing in written, but the following was mentioned recently: No pragma messages in source code to force todo messages to be visible in the compiler. An issue should be created in the issue-tracker instead.","LINK TO ISSUE TRACKER"
Ind_40,"A TODO should always be accompanied by a task nr, in our case the JIRA task ID. So the comment would be // TODO (ABC-123): Implement rare case X which is not currently handled. Having a TODO without a task reference is reason for the pull request not to be merged.","LINK TO ISSUE TRACKER"
Ind_42,"Preferably with name of author, date, and rationale. Note that this is in a small organization  (<20 developers). ","LINK TO ISSUE TRACKER"
Ind_49,"No, but we have a convention that almost everybody uses for TODOs. That is ""TODO (%svn username%)"". We also often add issues for technical debts in Jira, following a review.","LINK TO ISSUE TRACKER"
Ind_51,"No official policy, but it is customary to include a reference to an entry on the issue tracker","LINK TO ISSUE TRACKER"
Ind_53,"Yes, notation is either //TODO or //FIXME, followed by date, developer who wrote this and only after that the explanation. If possible, related ticket ID. No active enforcement on this. For really dirty code, we use #warning, but commonly this is resolved before merging to main branch.","LINK TO ISSUE TRACKER"
OSS_1,"TODO is a reminder and may be moved to an issue in the tracker","LINK TO ISSUE TRACKER"
OSS_2,"The policy is to create tasks on our issue tracker so to ensure anything that needs to be done gets scheduled.","LINK TO ISSUE TRACKER"
OSS_3,"We have an issue tracking system where we manage things that need doing.","LINK TO ISSUE TRACKER"
OSS_7,"ToDos are fine, but generally future work shouldn't be documented in code instead in tickets.","LINK TO ISSUE TRACKER"
OSS_23,"Tech-Debt, which means bad architectural constructs that will be taken deliberately are documented in form of a payback plan upfront, which is usually a ticket in our jira or github issue tracker.","LINK TO ISSUE TRACKER"
OSS_37,"Some ban TODO style comments and require tickets to be raised","LINK TO ISSUE TRACKER"
OSS_41,"The typical keyword ""[WIP]"" denoting work-in-progress is put in the Pull Requests on GitHub repo.","LINK TO ISSUE TRACKER"
OSS_42,"For TODOs: Prefer specifying a issue id over a username. A well-written issue provides a permanent history that won’t change teams, leave Google, or forget. It also adds additional context by including a full description, related CLs, and status updates. Example - TODO(b/123321): Implement this when ...","LINK TO ISSUE TRACKER"
OSS_44,"No. We use other means of keeping track of this (GitLab issues)","LINK TO ISSUE TRACKER"
Ind_50,"You can't push code to develop branches with TODO's or FIXME's. They need to be resolved directly or documented somewhere else.,"NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Ind_45,"No, delivered code shall be free from annotations, but it is not. We also do not use a tool to check for code annotations.","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Dev_1,"Our CICD workflow prevents TODO, Fixme, etc comments from proceeding past the DEV branch. These should have a task opened in the backlog instead.","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Per_15,"Not written, but are strongly discouraged.","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Per_6,"MUDO: this is a todo that really must be done before putting the code in production (it could be used to indicate something that needs to change after something else is finished, and for that reason cannot be done properly right now)""","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Per_19,There should be no annotations at all. TODOs need to go on tasks in the backlog and FIXMEs need to be fixed before merging into the main branch and/or releasing.,"NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Per_20,They should never be used.,"NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Per_39,"No hard policies, but it is far from preferred.","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Ind_13,"Our CICD workflow prevents TODO, Fixme, etc comments from proceeding past the DEV branch. These should have a task opened in the backlog instead.","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Ind_19,"Also, feature branches are used and code is only merged after it passes a code review (through the use of pull requests).""","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
OSS_1,"FIXME must be fixed before release, preferably before commit.  ","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
OSS_38,"Yes, several. Example: ""FIXME"" is for critical tasks = MUST be completed before a merge. We have an automated git hook that checks no FIXMEs are present in merged code.","NEVER ANNOTATE (IN A STABLE RELEASE BRANCH)"
Ind_19,"No policy within the organisation, but sometimes a policy within the team/project.","DECISIONS LEFT TO THE TEAM"
Ind_24,"Tech leads of dev, test and ops sometimes follow different implementation and design practices depending on tools and frameworks.","DECISIONS LEFT TO THE TEAM"
OSS_16,"We also utilize a ""# TODO: "" annotation internally, but no formal policies regarding annotations in general.","DECISIONS LEFT TO THE TEAM"
OSS_34,PyCharm provides automated support for TODO and additional annotations.  I generally use TODO. ,"DECISIONS LEFT TO THE TEAM"
OSS_43,"No, but I have my own policies: TODO(issue/12313) to link to a bug or something, and only if I am actually going to do it. For anything I am not realistically going to do but that might be the source of a future bug or feature request, just NOTE.","DECISIONS LEFT TO THE TEAM"
OSS_28,"Since my text editor does not have a detailed, flexible, or reliable bookmarking system, I use unique strings to mark places in the source code that are under active development. I use ""qq"" for most current places, ""qqq"" for foreground (immediate) tasks, and ""q1"" for places that need to be looked at before public release. These notations can be extended to ""qqqq"", etc., and ""q2"", etc.","DECISIONS LEFT TO THE TEAM"
Ind_21,"Yes we do: no TODO's without names or initials of the engineer.","DECLARE YOUR IDENTITY WHEN INTRODUCING TD"
Ind_42,"Preferably with name of author, date, and rationale. Note that this is in a small organization  (<20 developers). ","DECLARE YOUR IDENTITY WHEN INTRODUCING TD"
Ind_49,"No, but we have a convention that almost everybody uses for TODOs. That is ""TODO (%svn username%)"". We also often add issues for technical debts in Jira, following a review.","DECLARE YOUR IDENTITY WHEN INTRODUCING TD"
Ind_53,"Yes, notation is either //TODO or //FIXME, followed by date, developer who wrote this and only after that the explanation. If possible, related ticket ID. No active enforcement on this. For really dirty code, we use #warning, but commonly this is resolved before merging to main branch.","DECLARE YOUR IDENTITY WHEN INTRODUCING TD"
OSS_1,"All markers must be annotated by the developer user name.","DECLARE YOUR IDENTITY WHEN INTRODUCING TD"
Ind_21,"The code is scanned by Sonar and warns you that you're committing a todo. You have to justify the existence of the TODO's to code reviewers.","USE OF TOOL SUPPORT"
Ind_24,"There are also automated code and requirement robot tests that check if specifications changes were followed cross-release with or without carried over work.","USE OF TOOL SUPPORT"
OSS_32,"TODO (automatically recognized by PyCharm)","USE OF TOOL SUPPORT"
Ind_32,"Hacks and workarounds are discouraged but, when absolutely needed, they are usually explained not in code but in documents that are in our knowledge base","DOCUMENT TD IN SHARED DOCUMENTS AND NOT IN THE SOURCE CODE"
Ind_34,"Nothing in written, but the following was mentioned recently: No pragma messages in source code to force todo messages to be visible in the compiler. An issue should be created in the issue-tracker instead.","DOCUMENT TD IN SHARED DOCUMENTS AND NOT IN THE SOURCE CODE"
OSS_12,"We utilize the annotation ""# HACK: "" for highlighting technical debt workarounds within our private source code.","DOCUMENT TD IN SHARED DOCUMENTS AND NOT IN THE SOURCE CODE"