DEV Community: Johannes Vollmer

Announcing Regex Nodes, a visual editor for Regular Expressions

Johannes Vollmer — Tue, 30 Jul 2019 11:56:29 +0000

Hi! In this post, I am present to you what I have built to simplify creating regular expressions for JavaScript: Regex Nodes.

Warning: The presented project is still work in progress and some features might be missing or may not work as intended. It does not work on mobile devices. See the github project for more information on which features are planned.

What are Regular Expressions?

Regular expressions are used to find certain patterns inside a given text. For example, it can be used to extract all images from an html page. The way to use regular expressions in JavaScript is to just type a textual representation of the pattern inbetween two slashes:

const regex = /<img.*?>/gim
htmlSourceCode.search(regex)

This code will search the htmlSourceCode for any occurrence of <img followed by the lowest repetition (*?) of any character (.), followed by a >. After the slash, we tell JavaScript to be case insensitive and to look for multiple matches, not just for the first.

The Approach of the Editor

The editor visualizes all components of a regex with a separate "Node".
Those atomic components can be composed by connecting the properties of the nodes. That way, you can compose complex regular expressions
without having to deal with overly complex text lines.

The following image shows the editor with the aforementioned regular expression.

In the center, the white rectangles describe the hierarchy of the expression.
The rightmost node is the top-level operator, which combine the atomic nodes on the left hand side to a single regular expression.

To edit a regular expression, simply visit the online editor, paste the expression /<img.*?>/gim where it says "Add Nodes" at the top, and then click the first suggestion. Be aware that padding spaces in the regular expression will not be ignored and may lead to unexpected results.

To see how this specific regex works, you will also have to edit the example text by clicking the button at the top right and then paste some HTML, as the default example text does not contain any image tags.

Why Nodes?

Nodes are more verbose than a textual regex, but enable you to understand even the most complex expressions. Also, the design of the editor will naturally prevent you from accidentally producing an incorrect regular expression.

This really sets regex nodes apart from other regex tools, where the user must first come up with a regular expression that will be checked afterwards.

Getting Started

As I have not yet done any user experience research on the interface design, I will just list the basic functionality here, in case you're stuck and don't see how to do a specific thing. However, learning by trying before looking things up is what I would recommend.

Select a node by clicking with your left mouse button. Selecting a node will display its regular expression at the bottom. You can lock your selection to the currently selected node by toggling the padlock at the bottom left.
Move a node by dragging with your left mouse button.
Connect or disconnect properties by dragging with your right mouse button.
Move the view by scrolling, or by dragging with your middle mouse button.
Add a node by clicking into the "Add Nodes" text field and choosing the desired node type. You can also paste a regular expression here.
Edit the example text which is displayed in the background by clicking on the button at the top right.

Finally

Thanks for reading! I hope you will find this editor useful for your own regular expressions.

Keep in mind that this editor is still work-in-progress, and I cannot make any guarantees concerning the reliability of the editor. Also, this App does not support mobile devices yet. To see what features are planned, see the github project. Don't hesitate to post an issue on github if something comes to your mind regarding the regex editor.

johannesvollmer / regex-nodes

Visualize and edit regular expressions for use in javascript.

Regex Nodes

This node-based regular expression editor helps you understand and edit regular expressions for use in your Javascript code.

If your regular expressions are complex enough to give this editor relevance you probably should consider not using regular expressions, haha.

Why Nodes?

One of the problems with regular expressions is that they get quite messy very quickly. Operator precedence is not always obvious and can be misleading. Nodes, on the other hand, are a visual hierarchy. A text-based regex cannot simply be broken into several lines or indented, because that would alter the meaning of the expression.

The other major benefit of nodes is that the editor will prevent you from producing invalid expressions. Other regex editors analyze the possibly incorrect regular expression that the user has come up with. The node editor will allow you to enter your intention and generate a correct regular expression.

In addition, nodes…

View on GitHub

Have fun!

The Foo, the Bar, the Ugly

Johannes Vollmer — Wed, 31 Jan 2018 23:33:28 +0000

Image source: cinetropolis.net

When I learned my first programming language, Java, I just threw my questions into google. The web™ offers tons of helpful guides, and of course we all know StackOverflow, but theres a minor problem with many of them.

Code Examples

Examples are undeniably one of the most effective way of learning. They are essential for any programming tip, tutorial, or guide. Glady, the majority of guides do have them.

Specifically: Bad Code Examples

Unfortunately, someone once decided it was a good idea to do code examples using completely fictional identifiers without any meaning; the good, the bad, the ugly: Foo, Bar, and Baz.

They have been used to name entities such as variables, functions, and commands whose exact identity is unimportant and serve only to demonstrate a concept. Wikipedia

Why are these words bad?

Let's have a look at an example of (an example using these keywords). OMG so meta!
This example demonstrates how interfaces in Java work:

interface Foo {
    void foo();
}

class Bar implements Foo {
    @Override 
    public void foo(){
        System.out.println("Bar");
    }
}

class Baz implements Foo {
    @Override 
    public void foo(){
        System.out.println("Baz");
    }    
}

// ... later
void baz(Foo foo){
    foo.foo();
}

Admit it: You didn't really read this example. It's just not fun to read. Relations between classes, interfaces and methods can only be learned by carefully reading the source code, maybe even only when already knowing a little bit about interfaces.

A key property of examples is that they can be related to. Thus, choosing a fictional and meaningless word contradicts the very definition of 'example'. By using Foo, you fail to provide context.

What should we do instead?

Wouldn't this example of interfaces be much easier to understand:

interface SomethingThatPurrs {
    void purr();
}

class Cat implements SomethingThatPurrs {
    @Override 
    public void purr(){
        System.out.println("*purring cat*");
    }
}

class Kitten implements SomethingThatPurrs {
    @Override 
    public void purr(){
        System.out.println("*purring kitten*");
    }    
}

// ... later
void makeThatThingPurrSomehow(SomethingThatPurrs purring){
    purring.purr();
}

Cats and Kittens create a context. It's suddenly very easy to see that both of them can purr, and how SomethinThatPurrs should somehow relate to both. That's because you know that cats and kittens both purr.

I've seen beginners wondering what Foo and Bar actually mean, until someone tells them that there is no hidden meaning with that. Some even think that Foo and Bar are funny, which in turn motivates teachers to construct examples using these names.

In my opinion, when trying to explain a concept, one should do all that can be done in order to help the learnee. Providing context by using specific names and well-known concepts helps a lot.

Conclusion

Foo and Bar do not provide context
Examples should provide as much context as possible
Foo and Bar are uncreative and boring
Kittens are cute and inspiring

Foo and Bar are said to origin in the military acronym "FUBAR", which expands to "Fucked up beyond all recognition". What a coincidence.

Don't be a Bracist

Johannes Vollmer — Fri, 10 Nov 2017 16:43:04 +0000

Trigger warning: This post assumes that racism should be avoided.

Despite being a student, I already know how time-consuming it can be to dig through other people's work. But there's a particular habit that makes reading code less awkward, and we all know it: Proper Formatting.

There are many online guides on how to format your code. Most IDE's even have a nifty tool that automatically formats your source files. But theres a tiny inconsistency which many of those tools and guides choose to ignore.

Common Brace Indentation

This post is all about the formatting of parantheses to group arguments and (curly) braces to group statements. JS, Java, C++, Rust, C and hundreds of other languages use these in a similar manner. Let's have a look at how braces are usually indented in Java:

// inside KittenFactory
public List<Kitten> getKittensByAge(int minAge, int maxAge, boolean useGloves){
    final Filter ageFilter = new AgeFilter(minAge, maxAge);
    if (useGloves) {
        ageFilter.useHands();
        if (ageFilter.hasAnyGloves()) {
            ageFilter.removeWatch();
            ageFilter.enableGloves();
        }
    }
    return this.getKittens(ageFilter);
}

We start to see a pattern here: Closing braces are indented to the same level as their parent method head or if-keyword. Content inside braces is indented one level more than their parent keyword and closing brace. But now, let me throw that same code with an alternative indentation style at you (sorry, mobile phone users):

public List<Kitten> getKittensByAge(int minAge, int maxAge, boolean useGloves){
    final Filter ageFilter = new AgeFilter(minAge, maxAge);
    if (useGloves) {
        ageFilter.useHands();
        if (ageFilter.hasAnyGloves()) {
            ageFilter.removeWatch();
            ageFilter.enableGloves();}}
    return this.getKittens(ageFilter);}

In case you are considering to write a comment about a missing closing brace, look again. It's right there. I hope you enjoy that feeling of confusion, because there's more:

public List<Kitten> getKittensByAge(int minAge, int maxAge, boolean useGloves){
    final Filter ageFilter = new AgeFilter(minAge, maxAge);
    if (useGloves) {ageFilter.useHands();
                    if (ageFilter.hasAnyGloves()) {ageFilter.removeWatch();
                                                   ageFilter.enableGloves();}}
    return this.getKittens(ageFilter);}

Common Paranthesis Indentation

I feel your confusion and disrespect, yet I can sense a weird feeling of familiarity deep inside of you. It's because we all have seen it before, but not with braces, but with parantheses:

factory.getKittensByAge(0.2,
                        0.3,
                        user.glovesAreAvailableFor("Peter",
                                                   2017,
                                                   Location.of("Peter")));

Heck, this formatting even was found in Oracle's formatting guide (officially outdated).

Wow.

Alternative Indentation

This style of indentation greatly reduces readability. The important source code moves more and more to the right, far away from all the other code. Also, you can see a bunch of closing brackets cuddling at the end. Imagine having to debug a missing parantheses in such a function call. It's a mess. But fear not! There are alternatives! And we already use them, but with braces, and not with parantheses. Have a look:

factory.getKittensByAge(
    0.2,
    0.3,
    user.glovesAreAvailableFor(
        "Peter",
        2017,
        Location.of("Peter")
    )
);

Yep, it's that simple. This style has some remarkable benefits: Linebreaks actually move code back to the left, and you can easily see, which closing bracket belongs to which function call. That's why we use that style for braces, after all. Also, having one special formatting rule less seems to be easier anyway.

That same indentation style can also be applied to if-statements and function parameter definitions:

if(
    this.factory.filterType.hasGloves()
    && this.user.canUseGloves() // '&&' is important, so place it left
){
    factory.enableGloves();
}

public void setAllFieldsAtOnce(
    double fluffiness,
    String name,
    double minAge,
    double maxAge,
    // ...
){
    this.fluffiness = fluffiness * Double.MAX_VALUE;
    // ...
}

Conclusion

So, please don't be a bracist. Pay parantheses the same respect as braces. They deserve it! In the end, they are both used to group elements. Plus, your code will be much more readable.

I am aware that you may not be in the position to change the coding style at your company, but you can at least share this idea with friends and coworkers.

I hope you enjoyed my first post ever on dev.to!