What was your first programming language, what other languages (if any) do you know now, and what tips do you have for those trying to learn any of those? Whether those tips are for beginners or even advanced, to do with APIs, or if you've got a good library to share.

Just for a moment, forget all of the technical pros and cons, the static typing, just-in-time compilation, operator overloading, object orientation to the max...

Is there a programming language that you've just found to be... fun?

Is there one that you'd pick above all else for personal or company projects, if you had your druthers, because you would simply be so excited to use it?

And then, is there something missing in that "fun" language that's preventing it from actually becoming a reality (i.e. small community, lack of libraries, maintenance ended in the 80s, etc.)?

Let's share our favourite mono fonts and maybe we can find some new favourites. I used to use whatever was inbuilt with Visual Studio and JetBrains' IDEs, but since JetBrains released their JetBrains Mono, I've started using it everywhere. I override the monospace font on every website with it. Never was a huge fan of Fira Code, Consolas, or the other popular ones. Personal taste. But somethings about JB Mono just speaks to me!

Are you a ligatures person? Personally, I love them :)

Pretty standard:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

The twist: come up with the most creative or unusual way to solve this in your language of choice.

Granted that it's highly subjective and opinionated, but what this author James Anderson states in this StackOverflow post very much resembles the voices of many like myself who are trying to switch from interpreted/dynamic languages to static and compiled ones like Java/C#. How do Java programmers tackle or respond to this stance?

When I visit Youtube, their algorithms somehow always manage to come up with the most provocative and mind aggravating political videos and force me to watch them! I go there to do something else and then it takes an entirely different direction.

I've decided to switch to listening to podcasts for a change, do you know any good one, especially in the areas of Web Development, Engineering Stories, Desktop Development, Windows/Linux, etc.?

Its been a while since we did one of these, which is a shame.

Create a program that takes is an input of the type: "d6 + 3" or "2d20 - 5", and return a valid roll.
The result should display both the actual rolls as well as the final result. The program should accept any valid roll of the type 'xdx'
Bonuses:

• Multiplication "d6 * 3"
• Division "d12 / 6"
• Polish notation "4d6 * (5d4 - 3)"

As a side note, it would be really cool if weekly programming challenges became a thing

My pick is Perl5. Even though a lot people (mostly those who’ve never touched Perl) say it’s a “write only” language, I think it does a lot right. It’s easy to prototype with, and it gives you a lot of freedom in how you want to solve a problem; which I think is one of the most important features of a programming language.

I’d like to know what your picks are!

Hey there,

I wanted to know which sets of passports grant together visa-free access to every country in the world, but I could not easily find that info online. So I figured that I could try to write a small program to determine these sets of passports myself, and then it occurred to me that it would probably be a fun programming challenge to organize, so here we go.

Here's the challenge.

1. Scrape the data you need for instance from The Henley Passport Index.
2. Design a clever algorithm to efficiently find out which are the smallest sets of passports that will grant you visa-free access to every country in the world.
3. Optional. Allow the user to specify which passports they already hold and find out which sets of passports would complement their passports well.
4. Optional. Rank the sets of passports by how easy it is to acquire citizenship in those countries.

The choice of the programming language is yours, bonus points if you write it in assembly 😂

Feel free to collaborate and share your solutions (the algorithms and the actual results) in the comments, and feel free to share your own twists to the challenge that could make it even more fun & interesting.

The person with the most clever, efficient and elegant algorithm wins!

Happy coding folks!

I've seen the programming challenges on ~comp as well as quite a few users who are interested in getting started with programming. I thought it would be interesting to post some 'mini-challenges' that all could have a go at. I'm certain that many of you might find these pretty straight forward, but I still think there's merit in sharing different approaches to simple problems, including weird-and-wonderful ones.

This is my first post and I'm a maths-guy who dabbles in programming, so I'm not promising anything mind-blowing. If these gain any sort of traction I'll post some more.

Starting of with...

TicTacToeBot

Info

You will be writing code for a programme that will check to see if a player has won a game of tic-tac-toe.

Input

The input will be 9 characters that denote the situation of each square on the grid.

• 'X' represents the X-player has moved on that square.
• 'O' represents the O-player has moved on that square.
• '#' represents that this square is empty.

Example:

|O| |X|
|X|X|O|    The input for this grid will be O#XXXOO##
|O| | |

Output

The expected output is the character representing the winning player, or "#" if the game is not won.

(e.g. The expected output for the example above is '#' since no player has won)

Background

There's been some talk on ~ before, and it seems like there are quite a few people who are either interested in, learning, or working in game development, so I thought this could be a fun programming challenge.

This one is fairly open-ended: make a game in 1 hour. Any game, any engine, don't worry about art or sound or anything.

Doing is the best way to learn. Most people's first project is something overly ambitious, and when they find that it's more difficult than they thought, they can get discouraged, or even give up entirely. This is why the 1 hour limit is important: it forces you to finish something, even if it's small. When you're done, you can come out of it saying you made a game, and you learned from it.

Chances are the game might not be fun, look bad, be buggy, etc. But don't worry about that, everyone's game will have problems, and if you do create something really fun or innovative, congratulations, you have a prototype that you can expand on later!

"Rules"

Like I said before, these "rules" are pretty simple: make a game in (approximately) 1 hour. You can use any tools you want. If you use external assets (art, sound), it's probably best you use something you have the rights to (see resources). If you're completely new to game development/programming, your goal could even be to finish a tutorial.

If you're the kind of person who tends to get carried away with these things, you might want to post a comment saying you're starting, then another one once you've finished your game.

Please share your finished game, I'm sure everyone would love to try them! If your game is web-based, it can be hosted for free on Github Pages or Itch.io. If downloadable, it can be hosted for free on Google Drive, Mega, Dropbox, Itch.io, etc.

Resources

Engines

If you're a beginner, a good engine to start with is LÖVE. It's very simple, and uses Lua, which is very easy to learn.

If you're familiar with another language, you could use a library to make it in that language. Some examples:

C++: SFML, SDL, Allegro

Javascript: kontra, Phaser, pixi.js

Python: pygame

Rust: Piston, ggez, Amethyst

If you want something more complex, consider Godot, Unity, or Unreal.

You can also try something visual like Construct, Clickteam Fusion, or GDevelop

Art

For such a short time constraint, I'd suggest you use your own "programmer art": just use some basic shapes. Your primary focus should be gameplay.

If you think you have time to find something, try looking on OpenGameArt.

Sound

You can make simple sound effects very quickly with sfxr (or in this case, a web port of sfxr called jsfxr).

This is an adapted version of Talking Clock from /r/DailyProgrammer.

The point of this thread is to post your code for solving the task. Other will comment with feedback and new ideas. Post what language (and version, if relevant) your code is written in.

Task description

Your task is to translate a 24-hour formatted time to words.

Input description

An hour between 00 and 23 followed by a colon followed by a minute between 0 and 59.

Output description

The time expressed in words, in 12-hour format followed by "am" or "pm".

Sample input

00:00
01:30
12:05
14:01

Sample output

It's twelve am
It's one thirty am
It's twelve oh five pm
It's two oh one pm

I'm mostly just curious what types of in-depth projects you all get up to. The weekly "what are you working on threads" are always full of cool things, so I am curious what people's self-rated most difficult or complex projects have been.

I'm a student of software engineering. I'm not a programmer yet, but I use software that is common among this crowd, like i3wm, Neovim and Emacs. I know how to find and read documentation. I've read the obnoxious How To Ask Questions the Smart Way. Every time I encounter an issue, I do my diligence. I go through the manuals, I google, I read the docs. My main editor, Emacs, has an extensive manual, with plenty of accurate details. I get that's a huge program (more like a platform, really), but let's just say that a black-and-white 650 pages PDF is not the most ADHD friendly thing in the world.

I'm aware that I chose a career that requires plenty of reading, but I happen to like it a lot and it seems like I have some aptitude for it. I had similar issues in my previous activities anyway. But it's discouraging trying to understand programming and complex software, only to be repelled by people who think everyone has their ability for concentration. Sometimes I completely lose track of time. I can sit on my computer and hyperfocus for up to 48 hours with 20 Chrome tabs open non-stop and Netflix on the background. I may seem productive, but I'm not reading anything. Maybe I read one paragraph or two, and 30 seconds later I can't remember what I was doing. But I still have tasks to accomplish, and sometimes I need help to find useful information on a 700 pages manual.

Luckily I have a great support and determination and have accomplished a lot, but my peers have no idea what I went through to get to where I am. What I don't have in natural born skills I compensate with a lot of raw effort. Everyone has their difficulties and I'm not seeking compassion, but I'd like to suggest people think twice before dismissing as "lazy" someone you know nothing about. That person might have a mental disorder, a reading disorder or even an intellectual disability. Do you wanna be the guy who told a dyslexic to just read the fucking manual?

EDIT: of course I get that time and energy are limited commodities... my point is: don't be an asshole about it. Do what you can and you wanna do, but there's no need to use hostile buzzwords when you communicate with less knowledgeable people. You're not even forced to answer... I much prefer not getting an answer than getting a hostile one.

Hi folks,

I figured this would be a good place to ask a rather simple question.

Where do I start to learn to code?

I'm in high school, so I have (some) time to dedicate to it, and it seems there are a plethora of websites/resources out there, so I ask: what do you recommend, and why has it worked for you? I have no prior experience. I believe that this would really help out in the long run, as I will graduate high school with an Associate's Degree in Business. Thank you!

EDIT: Thank you for all your responses! I'll start with Python and move on from there. You guys have been a great help, and I'll vote you up or reply.

One big thing that has made maintenance of my older code easier has been considering the concept of cyclomatic complexity. In particular, limiting conditional checks to exceptional cases as much as is reasonable has made it easier to focus on the "happy" path of code execution and easily track down the errors, and the limited nesting depth has made things easier to read as well. Overall, my code remains relatively flat and I'm not branching through layers of logic trying to track down a simple bug.

What are some simple things you do to keep your code from being a massive headache long-term?

Overview

If you've spent any significant amount of time programming, then you've probably heard discussions about imperative, functional, and declarative programming. These discussions are often mired in technical knowledge and require a fair amount of intuition when trying to grasp the differences between the examples placed in front of us. These different programming styles, usually called programming "paradigms", are discussed as if they exist within a vacuum with complete and total isolation from one another. This only furthers the confusion and frustration among newer programmers especially, which runs counter to the goal of instructing them.

In this post I'll be taking a look at the oft-neglected intersections where these paradigms meet with the hope that the differences between them will be better understood by reframing our existing knowledge of programming basics.

Note: I'll be using PHP for my code examples and will try to provide comments when necessary to point out language quirks.

Understanding Fundamentals is Imperative

Let's start by first reviewing the most basic, fundamental programming paradigm: imperative programming. The term is a bit strange, but the important thing to understand about it is that imperative programming refers to writing software as a series of instructions where you tell the computer how to solve a specific task. For example, if we need to add together a bunch of numbers inside of an array, we might write code that looks like this:

$numbers = [ 8, 31, 5, 4, 20, 78, 52, 18, 96, 27 ];
$sum = 0;
foreach($numbers as $number) {
    $sum += $number;
}

This is a pretty typical example that you've probably encountered in some form or another at some point in your programming studies or career--iterate over an array one element at a time from the first element to the last and add the current element to some accumulating variable that starts at 0. The kind of loop you use may differ, but the general format of the solution looks the same. This is very similar to the way the computer itself performs the task, so the code here is just a relatively human-friendly version of the actual steps the computer performs. This is the essence of imperative programming, the basic building blocks of everything you learn early on.

Abstract Concepts

As the software we write gets larger and more complex, we then tend to rely on "abstractions" to simplify our code and make it easier to understand, reuse, and maintain. For example, if we've written a program that adds arrays of numbers together, then we probably aren't doing that in only one place. Maybe we've written a tool that generates reports on large data sets, such as calculating the total number of sales for a particular quarter, gross profit, net profit, remaining inventory, and any number of other important business-related metrics. Summing numbers could be so common that you use it in 30 different places, so to avoid having to maintain 30 separate instances of our number adding code from above, we define a function:

function sum($numbers) {
    $sum = 0;
    foreach($numbers as $number) {
        $sum += $number;
    }

    return $sum;
}

We do this so frequently in our code that it becomes second nature. We attach so many names and terms to it, too: DRY, abstraction layers, code reuse, separation of concerns, etc. But one thing experienced programmers learn is to write their functions and object and interface methods in such a way that anyone who uses them doesn't need to care about the underlying implementation details, and instead only need to worry about the method name, expected arguments (if any), expected return type (if any), and expected behavior. In other words, they don't need to understand how the function or method completes the intended action, they only need to declare what action they want performed.

A Declaration of Understanding

Anyone who has looked into the concept of the declarative programming paradigm should find those last words familiar: "they don't need to understand how the function or method completes the intended action, they only need to declare what action they want performed". This is the oft-touted explanation of what declarative programming is, the difference between detailing "how" and declaring "what", and I believe that it's this great similarity that causes imperative and declarative programming to become heavily entwined in a programmer's mind and makes it difficult to understand. Take this common example that authors tend to use to try to detail the difference between declarative and imperative programming:

// imperative
function sum($numbers) {
    $sum = 0;
    foreach($numbers as $number) {
        $sum += 0;
    }

    return $sum;
}

// declarative
function sum($numbers) {
    return array_reduce($numbers, fn($x, $y) => $x + $y, 0);
}

The authors will go on to state that in the imperative example, you tell the computer how to sum the numbers, whereas in the declarative example you don't tell the computer how to do it since you don't know anything about the reduce implementation, but intuitively it still feels as if you're telling the computer how to perform its task--you're still defining a function and deciding what its underlying implementation details are, i.e. the steps it needs to take to perform the task, even if its details are abstracted away behind function or method calls that could have varying implementation details of their own. So how the hell is this any different from defining functions like we do in imperative programming?

The answer is simple: it isn't. We've used so many names and terms to describe functions and methods in our ordinary imperative programming, but the truth is that a well-defined function or method serves as a declarative interface to an imperative implementation. Put differently, declarative programming is defining and utilizing simple interfaces that describe what you want accomplished while the underlying implementation details are inevitably written using imperative code.

Functional Differences

Now we can finally tackle one of the biggest trends in programming right now: the functional programming paradigm. But to understand this paradigm, it's important to understand what a "function" is... from a mathematical perspective.

Yes, I know, math tends to be a enthusiasm sink for many, but don't worry, we're not actually going to be doing math. We only need to understand how math treats functions. Specifically, math functions usually look something like f(x) = {insert expression here}, which is loosely equivalent to the following code:

function f($x) {
    return {insert expression here};
}

The important thing to note about functions in math is that you can run them a theoretically infinite number of times on the same input x and still get the same return result. Unlike in a lot of the programs we can write, math functions don't produce side effects. Files aren't written to or destroyed, database entries aren't deleted, some global counter somewhere isn't incremented, and your x doesn't suddenly change. The idea behind functional programming is to embody some of that nature of mathematical functions because they're predictable and always reproducible, and therefore simple to test as well. For example, take the following:

// not functional
function increment(&$x) { // pass by reference--$x will be modified outside of this function!
    $x++;
}

$x = 1;
increment($x);
increment($x);
increment($x);

// functional
function increment($x) { // pass by value--$x will NOT be modified outside of this function!
    return $x + 1;
}

$x = 1;
$y = increment($x);
$y = increment($x);
$y = increment($x);

Note that the first example will change the value of $x on each call, meaning each subsequent call of increment($x) produces a different result. Meanwhile the second example doesn't change $x and so the return value of increment($x) is always the same. This may seem like a silly example, but in larger, more complex software this can be significant. So now that we have an understanding of functions from a mathematical perspective, we have everything we need to actually understand what functional programming is.

Functional programming is a subset of declarative programming. Just like in declarative programming, you use simple interfaces to tell the program what you want to do rather than how to do it. But unlike declarative programming as a whole, functional programming imposes some additional restrictions on what you should and shouldn't do:

• You should encapsulate behavior in pure functions, which always give a consistent output for a given input and don't have side effects.

• You should write functions in such a way that you can compose them together, allowing you to combine and chain behavior to produce new functions or use the output of one as the input for another.

• You should avoid side effects as much as possible.

• You should avoid mutable state (e.g. changing the values in a variable).

• You should avoid sharing state between components.

These restrictions would require an entirely separate post on their own to properly cover and have been covered so many times in so many ways by others elsewhere that it would be superfluous for me to try to add anything more. It's important to note, however, that these restrictions are imposed because they provide some key benefits. By avoiding side effects and by avoiding mutable and shared states, the code you write becomes more predictable and tracing the behavior of an algorithm becomes far simpler. By writing pure, composable functions, you create reusable building blocks that can be strung together in virtually any configuration with predictable results. This makes writing, reading, maintaining, and debugging code easier and less error-prone.

That said, I feel that it's important to note that in the real world when writing practical software that users can interact with, it's simply not possible to completely avoid side effects or mutable state. The very act of creating and updating database entries is itself an act of mutating state, which runs contrary to functional programming principles and is essential for many important software projects. But even if you can't adhere strictly to functional programming principles, it's possible to benefit significantly from being aware of them and integrating them into your own software development strategies.

Let's consider a more practical example to illustrate this. Imagine that you've built a social media website and you're trying to test a push notification system that will be triggered when your user receives a new message. Now imagine your code and unit tests look something like this:

function sendNotification(&$message) { // pass by reference--$message will be modified outside of this function!
    $notification_system = new NotificationSystem();
    if(!$message['sent_push_notification']) {
        $notification_system->sendPushNotification($message);
        $message['sent_push_notification'] = true;
    }
}

function testSendNotification() {
    $message = [
        'user_id'=>'{some_id}',
        'contents'=>'Hi!',
        'sent_push_notification'=>false
    ];

    sendNotification($message);
    sendNotification($message);
}

At a quick glance you probably wouldn't be aware of why the second message didn't send, but the fact that our sendNotification() function mutates the state of the data provided to it is the culprit. This is code that doesn't adhere to functional programming principles since the data provided to it is mutated. As a result, running the function multiple times on the same variable doesn't result in the same behavior as the first call. If we wanted to work around this without adhering to functional programming principles then we would need to manually set $message['sent_push_notification'] = false; between function calls, which makes our unit tests potentially more error-prone. Alternatively we can make a simple change to adhere better to those functional principles:

function sendNotification($message) { // pass by value--$message will NOT be modified outside of this function!
    $notification_system = new NotificationSystem();
    if(!$message['sent_push_notification']) {
        $notification_system->sendPushNotification($message);
        $message['sent_push_notification'] = true;
    }

    return $message;
}

function testSendNotification() {
    $message = [
        'user_id'=>'{some_id}',
        'contents'=>'Hi!',
        'sent_push_notification'=>false
    ];

    sendNotification($message);
    sendNotification($message);
}

Now both notifications will be sent out, which is what we would intuitively expect. You should also notice that the above is also a blend of imperative, declarative, and functional programming. Our function definitions have imperative code, our sendNotification() function adheres to the functional programming principle of avoiding mutable state (well, mostly), and our NotificationSystem object provides a declarative interface for sending a push notification for a message.

Final Thoughts

By viewing these three paradigms not as completely separate concepts but as layers on top of one another, where functional programming is a type of declarative programming which is implemented using imperative programming, we can stop being confused by their similarities and instead find clarification in them. By understanding that imperative programming is the backbone of everything, that declarative programming is just simplifying that backbone with simple interfaces, and that functional programming is simply adding some additional guidelines and restrictions to the way you write code to make it more consistent, reusable, and predictable, we can start to see that we're not choosing one programming paradigm over another, but instead choosing how much consideration we place on the design of the programs we write. Except in purely functional languages, functional programming isn't some alien concept distinct from imperative or declarative programming, but is instead a natural evolution of the two.

There are a lot of details I've glossed over here. Each of these programming paradigms is far too detailed to include a proper analysis in an already lengthy post that tries to separate them from each other and clarify their differences. Blog articles exist in a thousand different places that can do each one far more justice than I can, and programming languages exist that completely cut imperative programming out of the picture. But for your average programmer slinging JavaScript, C, Rust, PHP, or what have you, I hope that this serves as a crucial starting pointing to understanding just what in the hell these functional programming enthusiasts are on about.

Preface

Recently I briefly touched on the subject of cyclomatic complexity. This is an important concept for any programmer to understand and think about as they write their code. In order to provide a more solid understanding of the subject, however, I feel that I need to address the topic more thoroughly with a more practical example.

What is cyclomatic complexity?

The concept of "cyclomatic complexity" is simple: the more conditional branching and looping in your code, the more complex--and therefore the more difficult to maintain--that code is. We can visualize this complexity by drawing a diagram that illustrates the flow of logic in our program. For example, let's take the following toy example of a user login attempt:

<?php

$login_data = getLoginCredentialsFromInput();

$login_succeeded = false;
$error = '';
if(usernameExists($login_data['username'])) {
    $user = getUser($login_data['username']);
    
    if(!isDeleted($user)) {
        if(!isBanned($user)) {
            if(!loginRateLimitReached($user)) {
                if(passwordMatches($user, $login_data['password'])) {
                    loginUser($user);
                    $login_succeeded = true;
                } else {
                    $error = getBadPasswordError();
                    logBadLoginAttempt();
                }
            } else {
                $error = getLoginRateLimitError($user);
            }
        } else {
            $error = getUserBannedError($user);
        }
    } else {
        $error = getUserDeletedError($user);
    }
} else {
    $error = getBadUsernameError($login_data['username']);
}

if($login_succeeded) {
    sendSuccessResponse();
} else {
    sendErrorResponse($error);
}

?>

A diagram for this logic might look something like this:

+-----------------+
|                 |
|  Program Start  |
|                 |
+--------+--------+
         |
         |
         v
+--------+--------+    +-----------------+
|                 |    |                 |
|    Username     +--->+    Set Error    +--+
|    Exists?      | No |                 |  |
|                 |    +-----------------+  |
+--------+--------+                         |
         |                                  |
     Yes |                                  |
         v                                  |
+--------+--------+    +-----------------+  |
|                 |    |                 |  |
|  User Deleted?  +--->+    Set Error    +->+
|                 | Yes|                 |  |
+--------+--------+    +-----------------+  |
         |                                  |
      No |                                  |
         v                                  |
+--------+--------+    +-----------------+  |
|                 |    |                 |  |
|  User Banned?   +--->+    Set Error    +->+
|                 | Yes|                 |  |
+--------+--------+    +-----------------+  |
         |                                  |
      No |                                  |
         v                                  |
+--------+--------+    +-----------------+  |
|                 |    |                 |  |
|   Login Rate    +--->+    Set Error    +->+
| Limit Reached?  | Yes|                 |  |
|                 |    +-----------------+  |
+--------+--------+                         |
         |                                  |
      No |                                  |
         v                                  |
+--------+--------+    +-----------------+  |
|                 |    |                 |  |
|Password Matches?+--->+    Set Error    +->+
|                 | No |                 |  |
+--------+--------+    +-----------------+  |
         |                                  |
     Yes |                                  |
         v                                  |
+--------+--------+    +----------+         |
|                 |    |          |         |
|   Login User    +--->+ Converge +<--------+
|                 |    |          |
+-----------------+    +---+------+
                           |
                           |
         +-----------------+
         |
         v
+--------+--------+
|                 |
|   Succeeded?    +-------------+
|                 | No          |
+--------+--------+             |
         |                      |
     Yes |                      |
         v                      v
+--------+--------+    +--------+--------+
|                 |    |                 |
|  Send Success   |    |   Send Error    |
|    Message      |    |    Message      |
|                 |    |                 |
+-----------------+    +-----------------+

It's important to note that between nodes in this directed graph, you can find certain enclosed regions being formed. Specifically, each conditional branch that converges back into the main line of execution generates an additional region. The number of these distinct enclosed regions is directly proportional to the level of cyclomatic complexity of the system--that is, more regions means more complicated code.

Clocking out early.

There's an important piece of information I noted when describing the above example:

. . . each conditional branch that converges back into the main line of execution generates an additional region.

The above example is made complex largely due to an attempt to create a single exit point at the end of the program logic, causing these conditional branches to converge and thus generate the additional enclosed regions within our diagram.

But what if we stopped trying to converge back into the main line of execution? What if, instead, we decided to interrupt the program execution as soon as we encountered an error? Our code might look something like this:

<?php

$login_data = getLoginCredentialsFromInput();

if(!usernameExists($login_data['username'])) {
    sendErrorResponse(getBadUsernameError($login_data['username']));
    return;
}

$user = getUser($login_data['username']);
if(isDeleted($user)) {
    sendErrorResponse(getUserDeletedError($user));
    return;
}

if(isBanned($user)) {
    sendErrorResponse(getUserBannedError($user));
    return;
}

if(loginRateLimitReached($user)) {
    logBadLoginAttempt($user);
    sendErrorResponse(getLoginRateLimitError($user));
    return;
}

if(!passwordMatches($user, $login_data['password'])) {
    logBadLoginAttempt($user);
    sendErrorResponse(getBadPasswordError());
    return;
}

loginUser($user);
sendSuccessResponse();

?>

Before we've even constructed a diagram for this logic, we can already see just how much simpler this logic is. We don't need to traverse a tree of if statements to determine which error message has priority to be sent out, we don't need to attempt to follow indentation levels, and our behavior on success is right at the very end and at the lowest level of indentation, where it's easily and obviously located at a glance.

Now, however, let's verify this reduction in complexity by examining the associated diagram:

+-----------------+
|                 |
|  Program Start  |
|                 |
+--------+--------+
         |
         |
         v
+--------+--------+    +-----------------+
|                 |    |                 |
|    Username     +--->+   Send Error    |
|    Exists?      | No |    Message      |
|                 |    |                 |
+--------+--------+    +-----------------+
         |
     Yes |
         v
+--------+--------+    +-----------------+
|                 |    |                 |
|  User Deleted?  +--->+   Send Error    |
|                 | Yes|    Message      |
+--------+--------+    |                 |
         |             +-----------------+
      No |
         v
+--------+--------+    +-----------------+
|                 |    |                 |
|  User Banned?   +--->+   Send Error    |
|                 | Yes|    Message      |
+--------+--------+    |                 |
         |             +-----------------+
      No |
         v
+--------+--------+    +-----------------+
|                 |    |                 |
|   Login Rate    +--->+   Send Error    |
| Limit Reached?  | Yes|    Message      |
|                 |    |                 |
+--------+--------+    +-----------------+
         |
      No |
         v
+--------+--------+    +-----------------+
|                 |    |                 |
|Password Matches?+--->+   Send Error    |
|                 | No |    Message      |
+--------+--------+    |                 |
         |             +-----------------+
     Yes |
         v
+--------+--------+
|                 |
|   Login User    |
|                 |
+--------+--------+
         |
         |
         v
+--------+--------+
|                 |
|  Send Success   |
|    Message      |
|                 |
+-----------------+

Something should immediately stand out here: there are no enclosed regions in this diagram! Furthermore, even our new diagram is much simpler to follow than the old one was.

Reality is rarely simple.

The above is a really forgiving example. It has no loops, and loops are going to create enclosed regions that can't be broken apart so easily; it has no conditional branches that are so tightly coupled with the main path of execution that they can't be broken up; and the scope of functionality and side effects are minimal. Sometimes you can't break those regions up. So what do we do when we inevitably encounter these cases?

High cyclomatic complexity in your program as a whole is inevitable for sufficiently large projects, especially in a production environment, and your efforts to reduce it can only go so far. In fact, I don't recommend trying to remove all or even most instances of cyclomatic complexity at all--instead, you should just be keeping the concept in mind to determine whether or not a function, method, class, module, or other component of your system is accumulating technical debt and therefore in need of refactoring.

At this point, astute readers might ask, "How does refactoring help if the cyclomatic complexity doesn't actually go away?", and this is a valid concern. The answer to that is simple, however: we're hiding complexity behind abstractions.

To test this, let's forget about cyclomatic complexity for a moment and instead focus on simplifying the refactored version of our toy example using abstraction:

<?php

function handleLoginAttempt($login_data) {
    if(!usernameExists($login_data['username'])) {
        sendErrorResponse(getBadUsernameError($login_data['username']));
        return;
    }

    $user = getUser($login_data['username']);
    if(isDeleted($user)) {
        sendErrorResponse(getUserDeletedError($user));
        return;
    }

    if(isBanned($user)) {
        sendErrorResponse(getUserBannedError($user));
        return;
    }

    if(loginRateLimitReached($user)) {
        logBadLoginAttempt($user);
        sendErrorResponse(getLoginRateLimitError($user));
        return;
    }

    if(!passwordMatches($user, $login_data['password'])) {
        logBadLoginAttempt($user);
        sendErrorResponse(getBadPasswordError());
        return;
    }

    loginUser($user);
    sendSuccessResponse();
}

$login_data = getLoginCredentialsFromInput();

handleLoginAttempt($login_data);

?>

The code above is functionally identical to our refactored example from earlier, but has an additional abstraction via a function. Now we can diagram this higher-level abstraction as follows:

+-----------------+
|                 |
|  Program Start  |
|                 |
+--------+--------+
         |
         |
         v
+--------+--------+
|                 |
|  Attempt Login  |
|                 |
+-----------------+

This is, of course, a pretty extreme example, but this is how we handle thinking about complex program logic. We abstract it down to the barest basics so that we can visualize, in its simplest form, what the program is supposed to do. We don't actually care about the implementation unless we're digging into that specific part of the system, because otherwise we would be so bogged down by the details that we wouldn't be able to reason about what our program is supposed to do.

Likewise, we can use these abstractions to hide away the cyclomatic complexity underlying different components of our software. This keeps everything clean and clutter-free in our head. And the more we do to keep our smaller components simple and easy to think about, the easier the larger components are to deal with, no matter how much cyclomatic complexity all of those components share as a collective.

Final Thoughts

Cyclomatic complexity isn't a bad thing to have in your code. The concept itself is only intended to be used as one of many tools to assess when your code is accumulating too much technical debt. It's a warning sign that you may need to change something, nothing more. But it's an incredibly useful tool to have available to you and you should get comfortable using it.

As a general rule of thumb, you can usually just take a glance at your code and assess whether or not there's too much cyclomatic complexity in a component by looking for either of the following:

• Too many loops and/or conditional statements nested within each other, i.e. you have a lot of indentation.
• Many loops in the same function/method.

It's not a perfect rule of thumb, but it's useful for at least 90% of your development needs, and there will inevitably be cases where you will prefer to accept some greater cyclomatic complexity because there is some benefit that makes it a better trade-off. Making that judgment is up to you as a developer.

As always, I'm more than willing to listen to feedback and answer any questions!

Been lurking for a week on tildes now and I am really glad this place exists. The crow here is exactly what I have been missing on Reddit for a while now.

Having said that, the whole Reddit situation has some-what motivated me to get the balls rolling on an idea that I have had for a while and I am looking for advice on the same.

I have often heard this phrase "Learn programming by building" but whenever I dive in to the resources, I fall flat due to the information overload and the general abstractness that the field has (I appreciate abstractness but here it demotivates me) and I have never found a proper resource that I could follow to actually build something instead of just blindly following tutorials and playing with them.

So, my question is how do I translate "learn by building a project" into a practical framework.

I know of 100 days of swift and I really like that approach however I don't think I want to start with swift or build an iOS app right now.

Lately, I've been working on a game in Godot. I've having a lot of fun, but I keep stressing out about my codebase becoming bad. I'm worrying about amassing technical debt, and having to rewrite huge amounts of code because of bad practices.

I've been reading best practices documentation for Godot, and learning about game programming patterns, but it's still a worry for me.

I'm wondering if this is a normal feeling, and how more experienced developers manage it.

It looks like it's been over a week and a half since our last coding challenge, so let's get one going. This challenge is a relatively simple one, but it's complex enough that you can take a variety of different approaches to it.

As the title suggests, write a program that accepts an arbitrary number of arrays, in whatever form or manner you see fit (if you want to e.g. parse a potentially massive CSV file, then go nuts!), and returns a single array containing all of the elements of the other arrays in sorted order. That's it!

Bonus points for creative, efficient, or generalized solutions!

It's been over a week since the last programming challenge and the previous one was a bit more difficult, so let's do something easier and more accessible to newer programmers in particular. Write a function that takes two strings as input and returns true if they're anagrams of each other, or false if they're not.

Extra credit tasks:

• Don't consider the strings anagrams if they're the same barring punctuation.
• Write an efficient implementation (in terms of time and/or space complexity).
• Minimize your use of built-in functions and methods to bare essentials.
• Write the worst--but still working--implementation that you can conceive of.