The Tech Beacon site has posted a list of thirty-five programming habits that make your code "smell", little things that you might do every day without knowing they could be causing issues with the long term maintenance of your code.

Bad habits are hard to break and even harder if you don't realize that what you're doing is undermining your work. If you know but don't care—that would be the worst. But you're here, aren't you?

As a programmer, I've seen a lot of poor practices, not just around code, but also around teamwork skills. I've been guilty of practicing many of these bad habits myself. Here are my top 35 bad programming habits, organized into four categories: code organization, teamwork, writing code, and testing and maintenance.

They've broken up the bad habits into different categories to make it a bit easier to consume:

• Code organization
• Teamwork
• Writing code
• Testing and maintenance

I think just about any developer out there as, at one time or another, fallen into the trap of one or more of these bad habits.

Peter Petermann has shared a few of his thoughts about right and wrong things to do when using Composer in your PHP-based applications. He offers suggestions based on some of the more wide-spread (but wrong, in his opinion) practices he's seen in several projects.

Last year I wrote a piece called “a few thoughts about composer and how people use it“. In that post I had a list of things which are problematic about how composer is used. That post got widely recognized, linked an visited, but in general those issues still exist.

However lately I’ve had even more people asking questions (either on related forums, irc or even irl) about problems that stem from issue number 2: people are using composer as an installer (and sometimes Number 3 because of Number 2). In that Post I already gave a quick opinion on how workflows with composer should look like, In this post I’ll try to give a few more pointers on how to use composer without creating a mess.

He then breaks up the remainder of the post into various practices he's seen and calling out developers for doing including:

• starting a project vs installing
• globally installed composer packages
• tagging and building

With each of his points he makes suggestions about what's wrong about the practice as well as some suggestions about how things could be done better.

In this new post to the Laravel Daily site Povilas Korop shares the second episode of his video podcast "Laravel Business" and talks about releasing Laravel packages.

Here’s the 2nd episode of my new Laravel Business video show where once a week I share the thoughts about Laravel-related work from the business perspective, as I’m transitioning from being a developer to being an owner of a small team.

Today I talk about packages – is it worth releasing Laravel packages? What are pros and cons? And can you earn money on it?

You can watch the episode either using the in-page player or directly over on YouTube.

Adam Culp has posted the latest episode of his "Run Geek Radio" podcast today - Episode #4: Standing desk, headphones, and firing bad customers.

Adam Culp speaks about his new Varidesk standing desk and launches a giveaway of a Varidesk. Also covers some of the reasons a developer may want to stand while working, and the benefits of standing while working. He also gives some hints and tips related to introducing the use of a standing desk into your daily habits.

He also mentions a new set of headphones he purchased to replace a broken set, and the various reasons why Plantronics Backbeat Pro was his choice. The main topic of firing a bad customer is then discussed by sharing possible reasons why a customer may be considered bad, how to communicate your intent, and some possible pitfalls that result from this potentially emotional event.

You can listen to this latest episode either through the in-page audio player, by downloading the mp3 or subscribing to the show's feed.

In two new posts to his site Stanislav Malyshev takes a look both forward and back at the PHP language, where it came from in the 5.4 version and ahead into the just released 5.6 version discussing the good, bad and road ahead.

With 5.6.0 having been released and 5.4 branch nearing its well-earned retirement in security-fixes-only status I decided to try and revive this blog. As the last post before the long hiatus was about the release of the 5.4, I think it makes sense to look back and see how 5.4 has been doing so far.

Having taken a look in the past, now it’s time to look into the future, namely 5.6 (PHP 7 is the future future, we’ll get there eventually). So I’d like to make some predictions of what would work well and not so well and then see if it would make sense in two years or turn out completely wrong.

In the look back at 5.4 he talks about some of the good (the release process, $this in closures) and some of the "not so good" including traits and the overall adoption rate. He also includes a few "don't know" items such as the overall performance and the inclusion of the mysqlnd driver. In the look forward he talks about the impact of things like constant expressions, phpdbg and function/constant importing (for better or for worse). He also briefly mentions two hurdles to the adoption of 5.6: OpenSSL becoming more strict and the overall adoption rate.

In this recent post to his site Ulrich Kautz takes a look at an interesting development in the PHP framework world - C-based frameworks installable as PHP extensions. He covers some of the good and bad things about this approach.

At the End of 2012 I had my first contact with a C-based PHP frameworks, namely YAF. Coincidently, some day afterwards Bruno from phpmaster.com pointed me towards Phalcon - a more modern interpretation of the same idea. So I was hooked.

In his "good idea" category he notes that it's faster because it's already loaded in on the request (no long list of includes) and the memory footprint is less than a PHP equivalent. The "bad" side of things mentions some pretty major hurdles though, including the small communities vs larger ones on PHP-based frameworks and the issues that could come with debugging/upgrading.

On the Coder's Lexicon site, there's a recent post talking about the author's love/hate relationship with PHP traits, a relatively new feature of the language that apps for more "drop-in" functionality similar to mixins in other languages.

When I saw the introduction of PHP traits in 5.4.0 I was eager to learn all about them and how they worked. [...] PHP traits, in my opinion, are handy and very flexible. I guess that is the “love” part of my relationship with them. [...] However, I feel that traits also meddle with a bit of the inheritance rules that have been proven time and time again. Is it possible to love as well as hate something at the same time?

He talks first about "the love" he feels for using traits in his code. He talks about their usefulness for geting around PHP's single inheritance structure and being able to "bolt on" functionality as needed. Then comes "the hate" of them, noting that in the wrong hands, they could lead to very messy and lazy coding practices (including the deadly diamond of death problem).

Brandon Savage has posted some of his thoughts on when it's okay to write bad code in your development lifecycle:

I’ve been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working - without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up. You know what? The component came out working, but when I was done it was ugly. Totally ugly. The code was bad. But I had a solution, and a solution that worked.

He points out that sometimes, doing things "the right way" can stifle creativity and experimentation - two things that a developer needs to solve the problems they face day to day. He notes that refactoring is a part of their job and moving from a rough prototype to a finished product often improves this skill and can find issues not discovered before.

This does NOT mean that developers can push bad code into a repository. Nothing lives longer than temporary code; see to it that your finished code is always good.

In this new post to PHPMaster.com, Callum Hopkins takes a look at one of the more recently added features of the PHP language, traits an tries to determine if they're a good or bad thing for PHP development.

In early March 2012, the PHP Group announced the release of PHP 5.4. Developer eagerly anticipated the release because of the many new features 5.4 would bring, the most sought after being traits. [...] Traits have have been generally accepted by the PHP development community, mainly because it’s a feature that exists within other programming languages like Java, C++, and Python. [...] Are they a feature which will help raise the level of PHP development, or are they just a fad?

The starts with a few reasons why he thinks traits are bad like their potential for abuse and the difficulties that could be caused by using them instead of something like an interface. On the good side, though, he mentions things like allowing for "multiple inheritance" and their addition showing growth in the language.

A while back there was an article that put a negative spin on PHP ("PHP: a fractal of bad design") and there was a huge community response to it with over 1400 comments on the post itself. Over on the DevShed forums, there's a lengthy new post that goes back over that article, piece by piece, and evaluates everything that was said.

As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject. Warning: This is just stupidly, ludicrously long. it takes an existing 5-page article and tears it apart nearly sentence-by-sentence.

He goes back through each of the sections - Stance, Arguments, Philosophy, etc - and includes quotes from the articles and his own impressions/thoughts about them. There's a section covering some of the individual complaints that were mentioned and things like PHP's OOP model and security.