BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Coding Standards Content on InfoQ

  • To Comment or Not to Comment

    Any developer has written at least one line of comment throughout his code. Some have written many comments in an attempt their code to be more explanatory. This article gathers some of the practices used in writing code comments.

  • Should We Rely on Language Constraints or Responsibility?

    Bruce Eckel, Michael Feathers, Niclas Nilsson, Keith Braithwaite, and others on the question: should languages be fully flexible, allowing the developers to tweak them as they like, and trusting they will be responsible in their work, or should there be clear constraints set in the language from its design phase to avoid mistakes that create bad code, hard to maintain or to read?

  • What is Velocity Good For?

    A recent discussion on the ScrumDevelopment Yahoo! group discussed the different uses and misuses for velocity. Should velocity be used a metric for productivity? Should it be used for iteration planning? What about longer term release planning?

  • Presentation: The Joys and Pains of a Long Lived Codebase

    In this presentation recorded at QCon SF 2008, Jeremy D. Miller shares lessons learned while developing a project over 5 years. He talks about his mistakes, what to avoid and how to design, code and test better.

  • ReSharper 4.5 Beta Promises Better Performance

    A few days ago ReSharper 4.5 Beta was released by JetBrains. This new version promise better performance and less memory consumption. New features include VB9 support, native MSTest support, "Go to Implementation" and improved compatibility with F#, Compact Framework and Silverlight.

  • Software Craftsmanship Manifesto: A Call to Arms

    A movement to promote Software Craftsmanship has been brewing for a few years. Since Agile 2008 last year they found a focal point with Uncle Bob Martin's claim that the Agile Manifesto needed amending with a new value: "Software Craftsmanship over Crap". Recently a group has created the Software Craftmanship Manifesto.

  • Rewards to Improve Team Habits?

    Sometimes teams have trouble starting new habits: writing unit tests, fix compiler warnings, not breaking the build. How do we help the team change these habits? Clint Shank designed a game to help people transition.

  • JetBrains Releases ReSharper 4.0 with Many Improvements, C# 3.0 Support

    JetBrains has released the much-anticipated productivity Visual Studio add-in, ReSharper 4.0. Resharper 4.0 includes many improvements and new features.

  • StyleCop – Microsoft's Style Enforcement Tool for C#

    Style enforcement has long been a hotly debated topic. Not only are their arguments over what style a team should standardize on, but also on whether or not there should be a standard style at all. In a move that is sure to add fuel to the flames, Microsoft has released StyleCop, the style enforcement tool they use internally.

  • Review Board - Online Code Review Tool

    Recently there has been a resurgence in interest in code reviews. InfoQ looks at Review Board, an open source application that helps facilitate the code review process, that has been gathering momentum in the open source community.

  • Opinion: Programming Languages Shouldn't Enforce Style, Teams Should

    Some believe that, if you write a large enough cookbook, there will always be a simple recipe to solve our programming problems. Taking it to an extreme, some want programming languages to limit developers to safe constructs and clean style. Reg Braithwaite skewers this idea, and challenges teams not to give up accountability for style, asking "Whatever happened to code reviews?"

  • Are You An Agile Architect?

    Vikas Hazrati recently posted an article on Agile Journal, defining his ideal characteristics of an Architect working in an Agile team, reflecting how the role of Architect has changed in light of Agile practices.

  • Peter Hosey of Adium on Code Reviews

    There is no question that formal code reviews catch bugs and can delay the inevitable "big ball of mud" that all successful projects seem to turn into. However, arranging a meeting for every check-in quickly becomes untenable on all but the most critical of projects. Peter Hosey talks about his experiences and how he conducts code reviews in Adium.

  • Is COM a Dying Technology?

    Does COM still have a place or is it a dead end technology?

  • Explicit vs. concise code in Ruby

    Ruby offers many ways of reducing code size. However, this can backfire in some situations. We look at one problem with Ruby's method for identifying nil and false values.

BT