"Include descriptive comments for each method," isn't bad advice. I mean, ideally, the method name and parameters would be descriptive enough that you don't need to add lots of comments, but more comments is rarely going to hurt things. Unfortunately, "include descriptive comments" usually decays into "include comments". And that's how we get piles of code like this one, from Patrick:

// 
// Function name   : CZiArecaRaidController::ReadAllRaidsetInfo
// Machine         : w7gre7
// Environment     : Visual Studio .Net 2008
// doxygen         : 
/// \fn   		CZiArecaRaidController::ReadAllRaidsetInfo(BSTR ContextInfo, IZiArecaDataCollection *pRaidsetInfoCollection, IZiArecaDataCollection *pVolumesetInfoCollection, IZiArecaDataCollection *pPhysicalDriveInfoCollection)
/// \brief		
/// \details		
/// \param		ContextInfo		
/// \param		*pRaidsetInfoCollection		
/// \param		*pVolumesetInfoCollection		
/// \param		*pPhysicalDriveInfoCollection		
/// \return		STDMETHODIMP 
/// \author		(redacted)
/// \date		24.01.2011 09:59:10
//
STDMETHODIMP CZiArecaRaidController::ReadAllRaidsetInfo(BSTR ContextInfo, IZiArecaDataCollection **pRaidsetInfoCollection, IZiArecaDataCollection **pVolumesetInfoCollection, IZiArecaDataCollection **pPhysicalDriveInfoCollection)
{
// ...
}

// 
// Function name   : CZiArecaRaidController::GetArecaErrorMessage
// Description     : 
// Return type     : string 
// Argument        : ARC_STATUS stat
// Author          : (redacted)
// Machine         : Lapgre5
// Environment     : Visual Studio .Net 2005
// Date/Time       : 05.06.2007 15:24:53
//
string CZiArecaRaidController::GetArecaErrorMessage(ARC_STATUS stat)
{
// ...
}

It's a holiday in the US today, so we're taking a trip into the past for a haunting classic about how things used to be. Original. -- Remy

Greg never thought he’d meet a real-life mentat.

“We’re so happy to have you aboard,” said Jordan, the CEO of IniTech. She showed Greg to the back end of the office, to a closed door marked with just one word: Frank. Jordan, not bothering to knock, opening the door.

John C works at a defense contractor, and his peers are well versed in C. Unfortunately, many years ago, a lot of their software started being developed in Java. While references are often described as "pointers, but safer," they are not pointers, so your intuitions about how memory gets allocated and released are likely to be wrong.

Which is definitely the case for John's peers. For example, in C, you generally want really clear understandings of who owns a given block of memory. You don't want to allocate memory and hand it off to another module without being really clear about who is responsible for cleaning it up later. This means that you'll often write methods that expect buffers and other blocks of memory passed into them, so that they don't have to worry about memory ownership.