Functional Aspects: They Say Stay Away From Ternary

I remember myself working on a project where ternary operators were used very actively in various situations. The more I read that code, the less comfortable I felt with it, and eventually caught myself on these questions:

  • Why are there so many cases of this syntax construct.
  • Should I (am I expected to) use the ternaries as well for the consistency reasons?
  • Is this code good or not generally speaking?
  • And more importantly, whether I should use ternaries a lot or stay away from them?

The more developers I spoke with, the more diverse perspective I heard. Eventually, I got very confused and made a decision to not use the weird thing (due to the absence of a good framework or a “mental model”). The decision has been followed almost to a degree it becomes a mantra but…

Continue reading →

Functional Aspects: Why Chaining Is Good

This is a short note about one of those things that annoy me quite often during code reviews. I am talking about primitive obsession used instead of some nicer alternatives. So let’s look at the code.

Here’s a simplified model class that stores amount of earned money and number of worked hours for a given day in an employee’s timesheet:

export class TimesheetDay {
  workDate: string;
  amount: number;
  hours: number;
  // ...
}

If we need to calculate the total amount of money earned by an employee within a given timeframe, the naive implementation would look like this:

public sumTimeSheetAmounts(weekDays: TimesheetDay[]): number {
  var sum = 0;
  for (let dayIndex = 0; dayIndex < days.length; dayIndex++) {
    const day = days[dayIndex];
    sum += day.amount;
  }
  return sum;
}

I see this kind of imperative bit-by-bit code in most of the pull requests. Does this code works? Yes, now it does. Is it easy to understand, maintain, extent? Definitely No, however even today in year 2017 many programmers would still disagree!

Continue reading →

Freelancer.com — a platform for trivial projects

Greg Young said in a couple of his presentations that every developer should at least once hire another developer (and pay him in cash out of his own pocket). Coincidentally, about the same time when I heard this phrase, I got an idea for a project that will heavily rely on source code parser. The main focus of the project is on the user experience. The convenient visual data representation and smart operations are the leverages that are going to make users effective and the project successful. There is one problem though…

Continue reading →

Ignore Tools, Infrastructure, and Process To “Maintain” Team’s Productivity

If you’re running and you’re followed
By some forty angry people –
Try to work it out quickly:
What’s upsetting them so much?

You must listen to everybody,
Give a piece of good advice.
But it’s strongly recommended
That you keep an even speed.

— Grigory Oster, “Bad Advice”

It’s year 2016 and your team is developing an application, a service, or other kind of software project. Here’s an incomplete list of suggestions which help the team to keep productivity where it is now.

Continue reading →

ObEq library page

ObEq for quick and easy object equality

 

Whenever I catch myself writing a piece of code similar to one I have written in the past I feel very uncomfy. DRY principle is well-known for a reason.

The right cure for duplicate code within a single project is refactoring via class extraction. For the code that’s written again and again in various projects a cure is just slightly different — package extraction is an answer.

So, implementing GetHashCode() and Equals() fifth time in yet another project was quite frustrating. It was even sadder to realize that whenever a new field is added to the target class, the hash code and equality methods must be revisited again but what will remind me or another user of that? Lastly, why should I even bother with these sorts of implementation details when I want to be focused on new feature works or a bug fix?!

It’s time to present ObEq, a tiny .NET open-source library that makes it easy to make equality happen. All you need to do is define an array of fields that are significant for hash code calculation and fieldwise comparison. Interested? Feel free to review it, use it, and fork it!