1. Apply Header docs
2. Define constants for literals
3. Apply Localization
4. Remove white spaces even unnecessary tabs
5. Memory management (including didReceiveMemoryWarning and viewDidUnload)
6. Notifications handling

When the project first started, the development team attempted to adopt some (though not all) of the concepts of the Scrum framework, an agile process based on empirical process control theory that focuses on transparency, inspection, and adaptation. The team implemented daily stand-up meetings and burndown charts, but chose not to adopt components to enable inspection, such as sprint planning, sprint review, and retrospective meetings.

As the project moved into the waterfall qualify phase — in which the development team needed to handle a constant stream of testing defects — the team’s scrum process ended. They would have to pick it back up when the next release started its development phase. This failure of the initial Scrum attempt was ultimately a consequence of not having adopted the processes of inspection; this lesson learned helped the team in their follow-on Scrum efforts.

In the development phase of a more recent release, the development team decided to start fresh and introduce the complete agile process based on the Scrum concepts and hallmarks. The team established a commitment to sprint planning, sprint review, and retrospective meetings. More importantly, they committed to process inspection and self-governance.

• Roles

  To fully adopt the Scrum way of doing things, the team needed to identify who on the scrum team would assume the three required roles of Product Owner, ScrumMaster, and Team. Initially, the development project manager was positioned as the primary Product Owner. The Team consisted of the existing development team members. A ScrumMaster was selected who established a sprint calendar of three- to four-week cycles, with start and end dates that didn’t necessarily line up with the waterfall process milestones; the team learned that sprint meetings scheduled close to waterfall milestones result in the team focus being shifted to one of these events, but not both, leaving an unfavorable result for the one that became neglected.

• Backlog

  For the sprint planning meeting, the development team started with the product backlog of candidates that the client had identified (in the concept and plan phases) for future release of the application. The Product Owner selected a subset of these items, which constituted the possible product backlog to be considered for the sprint. During the sprint planning meeting, the development team committed to the product backlog items they believed they could complete during the sprint, and from that built the sprint backlog, which was the tasks, task estimates, and assignments that the team would actually work on during the sprint.

• Reviews

  At the end of each sprint, the development team held a sprint review meeting. The purpose of this meeting was to demonstrate to the stakeholders what had been completed in the sprint, and provide a timely opportunity for the stakeholders to comment and ask questions, possibly resulting in a list of desired changes. Such changes and any missing or incorrect functionality were added to the product backlog for the next sprint.

• Retrospective

  At the end of each sprint, the development team also held a sprint retrospective meeting to review what went well during the sprint and what could be improved upon. Based on this feedback, they changed their processes as appropriate and added non-functional action items to the product backlog.

• Schedule

  The typical schedule was to hold the sprint review and sprint retrospective meetings on the same day at the end of the sprint, followed by the sprint planning meeting for the next sprint on the following day. These meetings were conducted within the Scrum time-boxing guidelines.

• Participants

  Client representatives (solution leaders) attended the sprint planning and sprint review meetings. Initially, the client’s interests were represented by the development project manager, but in later sprints, the development team was able to pull in the solution leaders and get direct client input and feedback through these key participants. This approach was purposeful; the team wanted to understand the processes and methodology well before expanding the circle of participants to include the solution leaders.

• User stories

  The development team also incorporated user stories into their planning. Although the client representatives (solution leaders) should be responsible for creating user stories, the development team did this instead, based on existing requirements, because the greater project was not yet committed to agile processes. The team then engaged the solution leaders in validating the user stories, collaborated to refine them and gain a greater understanding of the requirements. This practice has greatly improved the understanding and accuracy of the requirements, and greatly reduced rework after the fact.

• Quality assurance

  While the development team has long used continuous integration, they recently incorporated automated testing into the development process. Work items were not considered complete until an automated test was available and merged into the testing tool. Daily builds and automated testing ensured that the code base was not broken as code was checked in. This resulted in higher quality code and fewer defects being found in the qualify phase. Coding items were not considered complete until the functionality could be demonstrated on a live server. Non-coding items, such as new processes or documentation, were published on the development team’s internal wiki and distributed to the team for review prior to being presented as complete at a sprint review meeting.

For more info visit http://www.ibm.com/developerworks/websphere/techjournal/0907_hines/0907_hines.html

http://akosma.com/2009/01/28/10-iphone-memory-management-tips/

http://www.mobileorchard.com/iphone-memory-management/

• In Objective-C, instance variables are initialized to zero automatically. Don’t add explicit initializations to nil or NO in an init method.

• Unless required in order to force floating point math, do not append .0, .f and .0f to floating point literals.

• Use CamelCase. Capitalize the first letter, including all letters in an acronym, in a class, struct, protocol, or namespace name. Lower-case the first letter, including all letters in an acronym, in a variable or function name.

• Use full words, except in the rare case where an abbreviation would be more canonical and easier to understand.

• Prefix C++ data members with “m_”.

• Precede boolean values with words like “is” and “did”.

• Use descriptive verbs in function names.

• Leave meaningless variable names out of function declarations.

• Objective-C method names should follow the Cocoa naming guidelines — they should read like a phrase and each piece of the selector should start with a lowercase letter and use intercaps.

• Enum members should user InterCaps with an initial capital letter.

• Prefer const to #define. Prefer inline functions to macros.

• #defined constants should use all uppercase names with words separated by underscores.

• Macros that expand to function calls or other non-constant computation: these should be named like functions, and should have parentheses at the end, even if they take no arguments (with the exception of some special macros like ASSERT). Note that usually it is preferable to use an inline function in such cases instead of a macro.

• #define, #ifdef “header guards” should be named exactly the same as the file (including case), replacing the ‘.’ with a ‘_’.

Cited from: http://webkit.org/coding/coding-style.html

C++ is the main development language used by many of Google’s open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain.

The goal of this guide is to manage this complexity by describing in detail the dos and don’ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively.

Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting.

One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another’s code and quickly understand it. Maintaining a uniform style and following conventions means that we can more easily use “pattern-matching” to infer what various symbols are and what invariants are true about them. Creating common, required idioms and patterns makes code much easier to understand. In some cases there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency.

Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.

Open-source projects developed by Google conform to the requirements in this guide.

Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language.

cited from: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

    1. Team members should not have access to Basecamp.

    2. Should not work on new features on build(release) day, just concentrate on stabilizing the existing features.

    3. There should be internal technical forum (for technical help) organization level. There should be categories like google groups.

    4. The skill sets of all employees should be available to all, so that we can consult the particular people for suggestions or help.

    5. Team lead should be there with build master while releasing the build to client, otherwise there is change to release wrong build.

    6. Team members should not contact external persons (other teams) on project work with out prior notice to Team lead.

    7. Team members should post their technical issues on multiple chat (like Skype), so that every one will be aware of the type of issues.
   
    8. Team members should obey their superior orders strictly.

    9. Be aware while uploading the build to App Store.

        a. The app store will read the info plist (preferences) file from the build and act according to it. For example, if you remove glossy effect from app icon by setting UIPrerenderedIcon to true, then app store will automatically removes the glossy effect from the application Icon it shows in info section.

        b. The app store will read the release build for localizations and append them in the localizations section in app info section. It will automatically shows the supported localizations instead of what you configured while uploading.

    10. Modules should be segregated in such way that there is no dependability on each other.But at the same time make sure that each team member is aware of each other’s modules and the way the implementation is been done.

    11. Certain instances it’s been seen that there is some technical differences. I would suggest in those moments its better we sort the help of someone else who is technically sound.

    12. Do lot of commits to svn with less files than one commit with more files, because its a time consuming process to figure out the buggy file (one exists) in the commit.

1. Adopt a critical yet playful attitude.
2. Take multiple passes through the code.
3. Add review comments directly to the code.
4. Focus on one goal per pass.

        Functionality:

• Does the code meet the business (functional) requirements?
• Is the logic correct?

        Class Design:

• Does each class have low coupling and high cohesion?
• Is the class too large or too complicated?

        Code Style:

• Is duplication of code avoided?
• Are any methods too long?
• Are typical coding idioms / standards followed?

        Naming:

• Are packages, classes, methods and fields given meaningful and consistent names?

        Error Handling:

• How are errors dealt with?
• Does the code check for any error conditions that can occur?

        Security:

• Does the code require any special permissions to execute outside the norm?
• Does the code contain any security holes?

        Unit Tests:

• Are there automated unit tests providing adequate coverage of the code base?
• Are these unit tests well-written?

If you have any additional strategies you have found particularly useful, please let me know.

Instead of x = x + 2, use x +=  2.

1. You get an issue assigned to you

2. You program what needs to be done.

3. You send the issue to another developer on your team. He can then in the system see *the diff* of what you did on that  issue. That way he doesn’t have to look at everything, just what you did on that particualar issue. He can then enter comments and linenumber. Then he sends it back to you as either ‘review – fix’ or ‘review – approved’. You then fix it according to the comments (or put in comments to explain why you did things that way), and send it back to ‘review’ until you get it back with ‘review – approved’.

That seems to work well for us. We catch lots of subtle bugs and readability problems that way. The time you spend reviewing an issue is then put on that issue in the timetracking system, so it’s understood that each issue will have some code review time spent on it.

2. Don’t ever discuss fixes to issues you have found during the meeting. Note down the issue, assign it to the devleoper , let him fix and checkin the code, mark the issue as fixed and then the moderator should verify the fix by doing a diff.

3. Don’t make it personal.

4. If you found the issue was caused by defect in spec or design investigate how the spec and dsign was approved in first place, why they were wrong ?

5. Team leader: if the team leader wants something changed, then change it.

6. Peer: peers make ‘suggestions’ for improvement – having heard the suggestion it is then the author’s priviledge to decide whether (and how) to act on each suggestion.

7. Inline commenting

8. What was the reasoning behind the approached you used and What was the reasoning behind the deviation from the standards here?