Heading 2

Heading 3

Heading 4

Heading 5

Heading 6

A well-designed article should have a clear visual hierarchy.

The h1 normally represents the article title, while h2 and h3 divide the article into logical sections.

Text Formatting

This is bold text.

This is italic text.

This is bold and italic text.

This is deleted text.

This is underlined text.

This is highlighted text.

This is small text.

This is H₂O.

This is X².

This is inline code.

This is Ctrl + C.

You can also use KPI abbreviations.

Here is a link GitHub that opens in the same tab. And GitHub will open in a new tab.

Images

Blockquotes

Data is valuable only when it helps someone make a better decision.

A longer blockquote can contain multiple paragraphs 🚀.

Analysis requires curiosity.

Visualization requires clarity.

Communication requires understanding your audience.

Nested Blockquotes

This is the first level.

This is the second level.

This is the third level.

Unordered Lists

• Sales
  • Revenue
  • Units
  • Orders
• Customers
  • New customers
  • Returning customers
• Products
  • Best sellers
  • Worst sellers

Ordered Lists

1. Data preparation
   1. Remove duplicates
   2. Handle missing values
   3. Standardize formats
2. Analysis
   1. Calculate KPIs
   2. Compare periods
   3. Identify anomalies
3. Reporting
   1. Build dashboard
   2. Present insights
   3. Recommend action

Task Lists

• Collect data
• Clean data
• Build data model
• Create measures
• Validate results
• Present findings

Definition List

Revenue

The total income generated from selling products or services.

Profit

The amount remaining after subtracting costs from revenue.

Margin

Profit expressed as a percentage of revenue.

KPI

A measurable value used to evaluate performance against a business objective.

Code

A simple Python calculation:

revenue = 275
quantity = 65

average_revenue = revenue / quantity

print(average_revenue)

SQL Example

SELECT
    category,
    SUM(revenue) AS total_revenue,
    SUM(quantity) AS units_sold
FROM sales
GROUP BY category
ORDER BY total_revenue DESC;

DAX Example

Total Revenue =
SUM ( Sales[Revenue] )

Power Query Example

let
    Source = Excel.CurrentWorkbook(){[Name="Sales"]}[Content],
    ChangedType = Table.TransformColumnTypes(
        Source,
        {
            {"Revenue", type number},
            {"Quantity", Int64.Type}
        }
    )
in
    ChangedType

When writing SQL, the SUM() function can be used to calculate totals.

Mathematical Expressions

1. Global Sets & Custom Macros

• Inline Sets: Let $x \in \R$, $y \in \C$, $z \in \Z$, and $n \in \N$.
• Vector Sum Macro (\vectorsum{n}): \(\vectorsum{5} = \vec{v}_1 + \vec{v}_2 + \vec{v}_3 + \vec{v}_4 + \vec{v}_5\)
• Highlight Macro (\highlight{math}): \(\highlight{\int_{0}^{\infty} e^{-x^2} dx = \frac{\sqrt{\pi}}{2}}\)

2. Physics & Quantum Mechanics (physics)

• Partial Derivatives: $\pdv{f}{x}$ and mixed second derivatives: \(\pdv[2]{f}{x}{y} = \pdv{}{x}\left(\pdv{f}{y}\right)\)
• Schrödinger Equation with Bra-Ket Notation: \(i\hbar \pdv{\Psi}{t} = \hat{H}\Psi \implies \mel{\psi_a}{\hat{H}}{\psi_b} = E_a \braket{\psi_a}{\psi_b}\)

3. Chemistry Equations (mhchem)

• Precipitation Equilibrium: \(\ce{Ag+(aq) + Cl-(aq) <=> AgCl(v)}\)
• Thermochemical Reaction with Conditions: \(\ce{2H2(g) + O2(g) ->[{Pt\text{ catalyst}}][{\Delta}] 2H2O(l)} \quad \Delta H = -571.6\text{ kJ}\)

4. Advanced Colors & Canceling (color / xcolor & cancel)

• Color Mixing & Hex Codes: \(\textcolor{blue!60!red}{\text{60\% Blue + 40\% Red}} \quad \text{and} \quad \textcolor{#ff5733}{\text{Hex Color \#FF5733}}\)
• Canceling Terms in Algebraic Simplification: \(\frac{(x - 1)(x + 3)\cancel{(2x + 5)}}{\xcancel{(2x + 5)}\bcancel{(x - 1)}} = x + 3\)

5. Alignment, Numbering & Extensible Arrows (mathtools & AMS)

• Numbered align Environment with Extensible Arrows: \(\begin{align} A &\xRightarrow[\text{decomposition}]{\text{heat}} \textcolor{red}{\ce{2NaNO3}} + \ce{O2} \\ B &\xrightarrow[k_{-1}]{k_1} \highlight{\sum_{i=1}^{n} X_i^2} \in \R \end{align}\)

Horizontal Rule

The horizontal rule below should be visually distinct.

Table

Video

Audio

Details and Summary

Footnotes

Data visualization is an important part of analytical communication.¹

A KPI should always be evaluated against an appropriate benchmark.²

Long-Form Paragraph

A professional analytical report should provide enough context for the reader to understand not only what happened but also why it happened and what should happen next. This means that the analyst needs to understand the business process behind the data. A beautifully designed dashboard can still fail if it presents irrelevant metrics, uses misleading comparisons, or forces stakeholders to perform the interpretation themselves. Good analytical communication therefore combines accurate calculations, appropriate visualizations, concise explanations, and actionable recommendations. The objective is not to overwhelm the reader with information but to make the important information easier to find and understand.

In the previous post, we shaped our data into exactly the form we wanted. Now it’s time to tell Vega how that data should be translated into positions, sizes, and colors on the canvas. This is where scales come in.

Scales are one of the most important concepts in Vega. Every chart uses them, whether you’re creating a simple bar chart or a highly interactive custom visual in Deneb. Once you understand scales, you’ll understand how Vega connects your data to the visual elements on the screen.

In this post, we’ll learn what scales are, why we need them, how they work, and the scale types you’ll use most often in Vega and Deneb.

What Are Scales?

A scale is a function that converts values from your dataset into visual values on the canvas.

Think of it as a translator between data space and screen space. Your dataset contains values like 120, 450, or 950, but the canvas only understands pixels. A scale is responsible for converting one into the other. Let’s use a simple dataset throughout this section.

Suppose our chart is 300 pixels tall. The sales values range from 0 to 1000, so we need to fit that range into a canvas that is only 300 pixels high.

Without Scales

If Vega didn’t have scales, you would have to calculate the pixel position for every value yourself. The normalization formula would look like this:

Now every sales value has to be converted manually.

Your mark would need to contain something like this:

{
  "y": {"expr": "height - (datum.sales / 1000) * 300"},
  "y2": {"value": 300}
}

That works… but it’s not very practical.

What happens when the data changes?

Imagine next month’s data looks like this.

The maximum sales value is no longer 1000. It’s 1600. Now your old calculation is wrong. A value of 1600 becomes:

Your bar is now 480 pixels tall on a canvas that’s only 300 pixels high. Part of the chart will be drawn outside the canvas. So you’d have to update the formula everywhere:

And if the maximum changes again next week? You have to edit the calculation again. That’s exactly the problem scales solve.

With Scales

Instead of calculating pixel positions yourself, you simply tell Vega:

• The domain of my data is the Sales column.
• The range is the height of the canvas.

{
  "name": "y",
  "type": "linear",
  "domain": {"data": "dataset", "field": "Sales"},
  "range": [{"signal": "height"}, 0]
}

Now Vega automatically figures out the minimum and maximum sales values and maps them to the canvas. For our first dataset, Vega internally does something equivalent to:

Notice that we never calculated these values ourselves. Vega did it for us. Now replace the dataset with the new one where sales go up to 1600. We don’t change the scale at all. Vega recalculates everything automatically.

The chart still fits perfectly inside the same 300-pixel canvas.

That’s the real power of scales. You describe the relationship between the data and the canvas once, and Vega automatically adapts whenever the data changes. Whether your sales range from 0–1000, 0–1600, or even 0–1,000,000, you never have to rewrite the positioning logic.

The “scales” Block

Scales are defined inside the scales block, which is a top-level property of a Vega specification.

{
  "scales": [
    {
      "name": "xScale",
      "type": "band",
      "domain": {"data": "dataset", "field": "Month"},
      "range": "width"
    }
  ]
}

Just like the data and marks blocks, scales takes an array. That means you can define multiple scales in the same visualization.

A typical chart has at least two scales:

• An x-scale for horizontal positioning.
• A y-scale for vertical positioning.

More advanced visuals often define additional scales for color, size, opacity, or even symbol shapes.

How Scales Work

Every scale has two important concepts: domain and range. The domain represents the values coming from your data. The range represents the visual values on the canvas. You can think of it like this:

Domain → Scale → Range

The scale takes a value from the domain and converts it into the corresponding value in the range.

The Most Common Scale Types

Vega supports many scale types, but you’ll use a few of them most of the time.

1. Band Scale

A band scale is used for categorical axes.

It’s the standard choice for:

• Bar charts.
• Column charts.
• Heatmaps.

{
  "name": "x",
  "type": "band",
  "domain": {"data": "dataset", "field": "Category"},
  "range": "width"
}

Each category gets its own evenly sized band across the canvas.

One special feature of band scales is that Vega also knows the width of each band. That becomes useful later when we create bars.

For example:

"width": {
  "scale": "x",
  "band": 1
}

tells Vega that each bar should occupy the full width of its category band.

2. Linear Scale

A linear scale is the most common scale for numeric values.

Use it for:

• Bar heights.
• Line charts.
• Scatter plots.
• Area charts.

{
  "name": "y",
  "type": "linear",
  "domain": {"data": "dataset", "field": "Sales"},
  "range": "height"
}

A linear scale preserves proportional distances.

If one value is twice as large as another, its visual position is also twice as far along the range.

This makes linear scales perfect for continuous numeric data.

3. Time Scale

Dates are continuous values, so Vega provides a dedicated time scale.

{
  "name": "x",
  "type": "time",
  "domain": {"data": "dataset", "field": "Date"},
  "range": "width"
}

Unlike a band scale, a time scale positions values according to chronological order rather than equally spaced categories.

This is the scale you’ll almost always use for line charts that show values over time.

4. Ordinal Scale

An ordinal scale maps categories to discrete visual values instead of positions.

The most common example is color.

{
  "name": "color",
  "type": "ordinal",
  "domain": {
    "data": "dataset",
    "field": "Region"
  },
  "range": ["#2563EB", "#EA580C", "#16A34A"]
}

Now each region receives a different color.

Ordinal scales can also map categories to shapes, symbols, or other discrete visual properties.

Using Scales Inside Marks

Defining a scale does not draw anything by itself. A mark has to reference the scale.

"marks": [
  {
    "type": "rect",
    "from": {"data": "dataset"},
    "encode": {
      "update": {
        "x": {
          "scale": "x",
          "field": "Category"
        },
        "y": {
          "scale": "y",
          "field": "Sales"
        }
      }
    }
  }
]

Here’s what’s happening:

• The x property takes the value from the Category field and passes it through the x scale.
• The y property takes the value from the Sales field and passes it through the y scale.

The mark never works with pixel values directly. It simply asks the scale to translate the data value into a visual value.

This is one of the reasons Vega specifications stay clean and reusable. Multiple marks can reference the same scale.

Why Does the Y-Axis Look Backwards?

One thing confuses almost everyone when they start using Vega.

If the range is "height", why do larger values appear lower on the canvas?

The answer is that the Vega canvas starts at the top-left corner.

That means:

• 0 pixels is at the top.
• Larger pixel values move downward.

For most charts, we want higher values to appear higher on the screen, so we reverse the range.

"range": [
  {"signal": "height"},
  0
]

Now the mapping works like this:

• The minimum value appears at the bottom.
• The maximum value appears at the top.

You’ll see this pattern in almost every Vega bar chart, line chart, or area chart.

Nice Scales

Sometimes the minimum and maximum values in your data produce awkward axis labels.

Suppose your sales values range from 13 to 97.

Without any adjustment, Vega might generate tick marks like:

13, 34, 55, 76, 97

Not very reader-friendly.

You can ask Vega to round the domain to nicer values.

{
  "name": "y",
  "type": "linear",
  "domain": {"data": "dataset", "field": "Sales"},
  "range": [{"signal": "height"}, 0],
  "nice": true
}

Now Vega expands the domain to something like:

0, 20, 40, 60, 80, 100

The underlying data stays the same, but the axis becomes much easier to read.

Starting the Scale at Zero

Bar charts usually start at zero because viewers compare lengths.

Vega lets you enforce that using the zero property.

{
  "name": "y",
  "type": "linear",
  "domain": {"data": "dataset", "field": "Sales"},
  "range": [{"signal": "height"}, 0],
  "zero": true
}

Even if your smallest value is 45, Vega expands the domain so the axis starts at 0.

For line charts, you don’t always want this behavior because it can flatten meaningful variation.

Padding Between Categories

Band scales also let you control the spacing between categories.

{
  "name": "x",
  "type": "band",
  "domain": {"data": "dataset", "field": "Category"},
  "range": "width",
  "padding": 0.2
}

Increasing the padding creates more space between adjacent bands.

A padding of 0 makes the bands touch each other.

Larger padding values make bars narrower and leave gaps between categories.

This is one of the easiest ways to improve the appearance of a column or bar chart.

A Complete Example

Let’s put everything together with a simple column chart.

{
  "$schema": "https://vega.github.io/schema/vega/v6.json",
  "width": 400,
  "height": 200,

  "data": [
    {
      "name": "sales",
      "values": [
        {"month": "Jan", "sales": 28},
        {"month": "Feb", "sales": 55},
        {"month": "Mar", "sales": 43},
        {"month": "Apr", "sales": 91}
      ]
    }
  ],

  "scales": [
    {
      "name": "x",
      "type": "band",
      "domain": {"data": "sales", "field": "month"},
      "range": "width",
      "padding": 0.15
    },
    {
      "name": "y",
      "type": "linear",
      "domain": {"data": "sales", "field": "sales"},
      "range": [{"signal": "height"}, 0],
      "nice": true,
      "zero": true
    }
  ],

  "marks": [
    {
      "type": "rect",
      "from": {"data": "sales"},
      "encode": {
        "update": {
          "x": {"scale": "x", "field": "month"},
          "width": {"band": 1, "scale": "x"},
          "y": {"scale": "y", "field": "sales"},
          "y2": {"scale": "y", "value": 0},
          "fill": {"value": "#2563EB"}
        }
      }
    }
  ]
}

This example contains everything we’ve learned so far:

• A categorical band scale for the x-axis.
• A numeric linear scale for the y-axis.
• A reversed y-range.
• A zero baseline.
• Nice axis values.
• Padding between the columns.

Common Scale Properties

Here are the scale properties you’ll use most frequently.

These few properties cover the majority of scales you’ll create in everyday Vega work.

Conclusion

Scales are the bridge between your data and your visualization. They take raw values from your dataset and translate them into positions, colors, sizes, and other visual properties on the canvas.

Once you understand domain and range, the rest of Vega becomes much easier to read and write. You’ll define scales once and reuse them across multiple marks, keeping your specifications clean and consistent.

In the next post, we’ll build on this foundation by looking at axes—the visual representation of scales. We’ll learn how to draw axes, customize labels, control tick marks, and make our Vega charts much easier to read.

In the previous post, we looked at how to get data into Vega. Once the data is in, the next step is to shape it according to your visualization needs. That’s where data transformation comes in.

In Vega, we can perform transformations right inside the data block of each dataset definition. Vega offers a wide range of built-in transformations, but in this post, we’ll focus on the most useful and commonly used ones. If you’re curious, you can explore the full list of available transformations here.

Transformations

Transformations come in many forms. You might want to add new columns, remove existing ones, filter rows, calculate statistics, perform lookups, or aggregate data—the list goes on.

All of these actions happen inside the transform property of a dataset. This property takes an array, so you can apply multiple transformations in sequence. Each transformation builds on the result of the previous one.

Let’s walk through some of the most useful transformations with examples and explanations.

1. Calculated Columns

If you’re coming from a Power BI background, the term calculated column should feel familiar.

In Vega, we can create new columns (or overwrite existing ones) using formulas. To do this, we use the formula transform with these properties:

1. type: For calculated columns, this should be formula.
2. as: The name of the new column. If the name already exists, it will be overwritten.
3. expr: The formula to be applied to each row.

Here, we need to understand the concept of datum in Vega. It represents the current row of the dataset (row context, Power BI folks!). You can access a field in the row using datum.ColumnName or datum['Column Name'].

Vega supports a wide range of expressions. You can check them out here.

{
  "data": [
    {
      "name": "exampleFormula",
      "values": [
        {"a": 9, "b": 7, "c": 5},
        {"a": 19, "b": 27, "c": 35},
        {"a": 99, "b": null, "c": 59}
      ],
      "transform": [
        {
          "type": "formula",
          "as": "Simple Addition",
          "expr": "datum.a + datum.c"
        },
        {
          "type": "formula",
          "as": "Logical Calc",
          "expr": "if( isNumber( datum.b ), datum['Simple Addition'] - datum.b, NaN )"
        }
      ]
    }
  ]
}

2. Aggregating

The aggregate transform is used to group and summarize data. You can perform operations like count, sum, average, min, max, variance, distinct, and more (full list here).

Key properties:

1. type: Must be aggregate.
2. ops: An array of aggregation operations to apply.
3. fields: An array of columns to aggregate—must match the size of ops.
4. as: Names of the new aggregated fields (also matches the size of ops and fields). If omitted, Vega auto-generates names like sum_sales, avg_rating, etc.
5. groupby: Optional. If specified, the aggregation will be grouped by the given fields.

{
  "data": [
    {
      "name": "exampleFormula",
      "values": [
        {"category": "SSC", "a": 9, "b": 7, "c": 5},
        {"category": "SSC", "a": 19, "b": 27, "c": 35},
        {"category": "HSC", "a": 99, "b": 79, "c": 59}
      ],
      "transform": [
        {
          "type": "aggregate",
          "ops": ["average", "min", "variance", "count"],
          "fields": ["a", "b", "c", "c"],
          "groupby": ["category"]
        }
      ]
    }
  ]
}

There are a few more optional properties for advanced behavior, but we can skip those for now.

3. Filtering

Filtering lets you include or exclude rows based on a condition. In Vega, you use the filter transform, which is super straightforward:

1. type: filter
2. expr: A condition that evaluates to true or false for each row and this transform only returns the rows where the expression evaluates to true.

Once again, datum is used to refer to each row while writing the expression.

{
  "data": [
    {
      "name": "exampleFormula",
      "values": [
        {"category": "SSC", "a": 9, "b": 7, "c": 5},
        {"category": "SSC", "a": 19, "b": 27, "c": 35},
        {"category": "HSC", "a": 99, "b": 79, "c": 59}
      ],
      "transform": [
        {
          "type": "filter",
          "expr": "datum.category == 'SSC' && datum.c > 30"
        }
      ]
    }
  ]
}

4. Lookups

If you’re familiar with Excel or Power BI, you know how powerful lookups can be.

In Vega, you can enrich a dataset by pulling values from another dataset using the lookup transform. This works just like LOOKUP functions (Excel’s lookup functions (like VLOOKUP, HLOOKUP, INDEX-MATCH, and XLOOKUP) are used to find specific data within tables and retrieve related information.) in Excel or the RELATED (In Power BI’s DAX, RELATED is a function used in calculated columns to retrieve a value from a related table, automatically following an existing one-to-many relationship.) function in Power BI.

Important properties:

1. type: lookup
2. from: The name of the dataset you’re pulling data from.
3. fields: Columns from the current dataset to match against.
4. key: Column in the second dataset to match with.
5. values: Columns you want to bring in from the second dataset. If omitted, the full matching row is returned as an object.
6. as: Names of the new columns being added. Required if fields has multiple values or values is omitted.

{
  "data": [
    {
      "name": "secondary",
      "values": [
        {"fullName": "Alice", "age": 19},
        {"fullName": "Bob", "age": 23},
        {"fullName": "Evans", "age": 39}
      ]
    },
    {
      "name": "primary",
      "values": [
        {"firstName": "Alice", "lastName": "Smith"},
        {"firstName": "Bob", "lastName": "Jones"},
        {"firstName": "Carol", "lastName": "Evans"}
      ],
      "transform": [
        {
          "type": "lookup",
          "from": "secondary",
          "key": "fullName",
          "fields": ["firstName", "lastName"],
          "values": ["age"],
          "as": ["age_1", "age_2"]
        }
      ]
    }
  ]
}

This code looks up the firstName from the primary table in the fullName column of the secondary table and returns the age column as age_1. Then it looks up the lastNames from the primary table in the fullName column of the secondary table and returns the age column as age_2.

⚠️ The dataset you’re looking from must be defined before the one doing the lookup, otherwise it won’t work.

5. Sorting

Sorting a dataset is another essential transformation. In Vega, we use the collect transform for this. It supports sorting by one or more columns in ascending or descending order.

1. type: collect
2. sort: An object with two keys:
   • field: An array of column names to sort by.
   • order: An array specifying the sort order for each field—either ascending or descending.

{
  "data": [
    {
      "name": "exampleTable",
      "values": [
        {"fullName": "Alice", "age": 19},
        {"fullName": "Bob", "age": 23},
        {"fullName": "Evans", "age": 39}
      ],
      "transform": [
        {
          "type": "collect",
          "sort": {
            "field": ["age"],
            "order": ["descending"]
          }
        }
      ]
    }
  ]
}

These are some of the most useful transformations you’ll find yourself using regularly. Vega supports many others like flatten, window, stack, fold, and so on. You can explore the full list here. And if there’s a specific one you’d like explained with examples, just let me know—I’d be happy to help!

Conclusion

Once your data is shaped and ready, it’s time to move on to the next step—scaling. In the next post, we’ll explore how to tell Vega where your data should go and how it should be mapped visually. Stay tuned!

The first step in any visualization is to get the data you want to work with. Vega is no different. Before you can show anything on the screen, you need to bring in the data—and Vega gives you several flexible ways to do just that. In this post, we’ll explore how to import datasets using the data block.

The ‘data’ Block

In Vega, datasets are defined inside the data block. As mentioned in the previous post, this block takes an array, which means you can define multiple datasets—each one as a JSON object.

To make things easier, Vega provides some helpful properties you can use for each dataset. Let’s take a look at a few of them and how they work:

• name: This is the only required property. Each dataset must have a unique name. If you use the same name more than once, the last one will overwrite the previous one. If you only provide the name and nothing else, you’ll end up with an empty dataset.

• url & source: Use url to load data from an external source. If you want to create a new dataset from an existing one, use the source property and reference the original dataset’s name. This is especially useful for filtering or transforming data.

{
  "data": [
    {
      "name": "jobs",
      "url": "https://cdn.jsdelivr.net/npm/vega-datasets@3.1.0/data/jobs.json"
    },
    {
      "name": "jobsCopy",
      "source": "jobs"
    }
  ]
}

In this example, the first dataset (jobs) is loaded from an external link, and then a second one (jobsCopy) is created as a copy.

• format: This defines how the data should be parsed. By default, Vega assumes external data is in JSON format. But if you’re working with CSV, TSV, or other formats, you can use the format property to specify the correct type.

{
  "data": [
    {
      "name": "jobs",
      "url": "https://cdn.jsdelivr.net/npm/vega-datasets@3.1.0/data/github.csv",
      "format": {"type": "csv"}
    }
  ]
}

• values: This is used when you want to hardcode data directly in the spec. The most common format is JSON, but you can also use CSV or other formats—as long as you declare it in the format property.

{
  "data": [
    {
      "name": "inlineJSON",
      "values": [
        {"a": 9, "b": 7, "c": 5},
        {"a": 19, "b": 27, "c": 35},
        {"a": 99, "b": 79, "c": 59}
      ]
    },
    {
      "name": "inlineCSV",
      "values": "a,b,c\n9,7,5\n19,27,35\n99,79,59",
      "format": {"type": "csv"}
    }
  ]
}

In the example above, we hardcoded the same dataset in two different formats. Take a look at how they show up in the code editor. Notice anything interesting? 🤔

The ‘data’ Block in Deneb

If you’re using Vega inside Power BI with Deneb, things work a bit differently—but also more conveniently.

When you drag columns and measures into the Deneb visual, it behaves just like the table visual in Power BI. Deneb automatically creates a dataset called dataset with the fields you’ve included. This dataset is exactly what you’d see in a Power BI table visual—with the same columns, measures, and row order.

To use this dataset in your Vega spec, you just need to reference dataset by name.

{
  "data":[
    {
      "name": "dataset"
    }
  ]
}

You might notice a few extra columns you didn’t add yourself. These are included by Deneb to support interactivity features like highlighting and filtering. We’ll dig into those later.

Example Datasets

Vega provides a collection of sample datasets in various formats that are perfect for learning and experimenting. You can explore them here. To use any of these datasets, just set the url like this: "https://cdn.jsdelivr.net/npm/vega-datasets@3.1.0/data/<datasetName.format>". Replace <datasetName.format> with the actual name and format of the dataset you want to use.

Creating a chart with Vega can feel overwhelming, especially when the chart is complex or interactive. But if you understand the core components of Vega’s syntax, you can break down the process into small, manageable chunks—and that makes everything a lot easier. In this post, we’ll go over those core building blocks so you can start thinking in Vega terms.

Core Components

Data visualizations can involve many steps, but broadly speaking, the whole process can be divided into three main parts:

• Getting and preparing the data
• Indicating what we want to visualize
• Describing how we want to visualize it

As our charts get more advanced, we’ll need additional components, but these three are the essentials for getting something on the screen.

In the previous post, we talked about the canvas and how to create one. Once we have our canvas, the first thing we need is data. We use the data block to bring in and prepare the data we want to visualize. This block is where you can import datasets, clean them up, and apply transformations.

Once the data is ready, we need to tell Vega what kind of data goes where. For example, in a column chart, we’ll usually have categories on the x-axis and numeric values on the y-axis. This kind of mapping is done using the scales block.

Finally, we need to tell Vega how we want to visualize the data. Do we want a bar chart? A line? An area chart? A scatter plot? These visual elements are called marks, and they’re defined inside the marks block.

So, the three components you absolutely need to get started are:

• data — what we’re visualizing
• scales — how that data maps to the canvas
• marks — what kind of visual elements we use to show the data

With just these three blocks, you can already get a chart on the canvas! It might not look very fancy, but it’s a great place to start. The basic structure with these components looks like this:

{
  "$schema": "https://vega.github.io/schema/vega/v6.json",
  "width": 500,
  "height": 200,
  
  "data": [ ],
  "scales": [ ],
  "marks": [ ]
}

Let’s look at a bar chart created using only these core components:

Other Components

As your visuals get more complex—or if you want to make them interactive—you’ll need to use a few more components. Here are the most common ones Vega offers:

• signals: This is where we define variables and parameters to make our visuals interactive. Think of it as adding logic to your visual.
• axes: While the scales block defines what kind of data goes where, the axes block tells Vega how to draw those axes—tick marks, labels, orientation, etc.
• legends: No surprise here—this is where we customize the legend of our chart.
• projections: If you’re creating a map, you’ll need this block to define how geographical data should be projected onto the canvas.

So, the top-level structure of a Vega spec with all these elements looks something like this:

{
  "$schema": "https://vega.github.io/schema/vega/v6.json",
  "width": 500,
  "height": 200,
  
  "data": [ ],
  "signals": [ ],
  "scales": [ ],
  "projections": [ ],
  "axes": [ ],
  "legends": [ ],
  "marks": [ ]
}

If you’re familiar with JSON, you’ll notice that each of these blocks are defined as a JSON array (A JSON array contains zero, one, or more ordered elements, separated by a comma. The JSON array is surrounded by square brackets [ ].
). That means we can include multiple datasets, multiple scales, multiple marks, and so on.

Why is that helpful? Hold your horses—we’ll explore that soon!

Now that we’re familiar with Vega, we can start building a logical understanding of its syntax. But before diving into the details, let’s take a step back and talk about something very basic—yet super important: the canvas.

What Is a Canvas?

If you’ve ever done any painting, you already know what a canvas is—it’s the surface where you paint your masterpiece. In Vega, the concept is pretty much the same. The canvas is where all the visual elements live.

The cool part? In Vega, you don’t need to explicitly create a canvas. Since Vega is just a structured JSON file, everything you write goes inside a pair of curly braces {}. These outermost braces automatically create a canvas for you.

So if you just type {} in the code editor, Vega technically creates a canvas. But—here’s the catch—you won’t see anything. Why? Because that canvas is 0 pixels wide and 0 pixels tall. It’s invisible.

Let’s Make It Visible

To actually see the canvas, we need to give it some dimensions. We can do that using the width and height properties. And to make things more obvious, let’s also give it a background color using the background property.

Here’s how that looks in Vega:

{
  "width": 250,
  "height": 100,
  "background": "grey"
}

And now, the result is something you can see—an actual grey canvas!

All the visual elements you create will be drawn inside this canvas. Think of it as the stage where your charts and marks perform.

We’ll talk about more customizations you can apply to the canvas later on. For now, let’s shift gears and look at something very helpful—the schema.

Canvas Coordinates

One concept that will come in handy throughout this series is how positioning works in Vega and Vega-Lite. The origin of the canvas is the top-left corner, which means the point (0, 0) is located at the top-left of the visualization. From there:

• The x-coordinate increases as you move to the right.
• The y-coordinate increases as you move downward.

This is different from the coordinate system many of us learned in school, where the origin is at the bottom-left and the y-axis increases upward.

Understanding this coordinate system makes it much easier to understand how scales and marks work, especially when we start positioning visual elements on the canvas. Play with the interactive visual below to see how the (x, y) coordinates change as you move around the canvas.

What Is a Schema?

By now, you know that Vega is a language that describes how visuals should look. Like any language, it has its own set of rules—a grammar, if you will. These rules are defined in what’s called a schema file.

When you include the schema in your code, the editor becomes smarter. It automatically checks your code for errors and highlights them right away. Super helpful!

You can include the schema using the $schema property at the top of your JSON:

{
  "$schema": "https://vega.github.io/schema/vega/v6.json",
  "width": 250,
  "height": 100,
  "background": "grey"
}

Technically, you can write Vega code without including the schema. In fact, we did that earlier just to display the canvas. But without the schema, you’ll probably end up spending hours debugging a missing comma or typo. Not fun at all!

So my advice? Always include the schema. It’s like having a grammar checker for your charts.

We learned in the previous post that Vega is a declarative language where we can create visualizations by declaring the components of the visuals using JSON.

In this post, we will learn about some of the features of the code editors for Vega. If you want to create a standalone visualization using Vega, you can use the online editor. If you are using Vega inside Power BI, Deneb provides a code editor for that.

Understanding how to navigate and use these editors will save you a lot of time later when your visuals get more complex or interactive. So, before diving into coding, let’s get comfortable with the tools we’ll be using.

Online Editor

The online editor for Vega and Vega-Lite is the easiest way to try and test any Vega or Vega-Lite code. You don’t have to download anything—you can use it in any browser. The online editor looks like the following picture:

It has three panes: the left pane is for writing the code, the top right pane is where the visuals are rendered, and the bottom right pane shows the raw data, parameters, and logs. The code pane and the visual pane are self-explanatory, but the data pane is extremely important to understand how Vega or Vega-Lite works.

The data pane has four tabs: LOGS, DATA VIEWER, SIGNAL VIEWER, and DATAFLOW VIEWER. We can see the error messages in the LOGS tab. The DATA VIEWER shows the datasets used in making the visuals. The SIGNAL VIEWER shows all the signals (signals are variables and parameters used to produce the visuals—we will learn about signals later). And the DATAFLOW VIEWER shows a graphical representation of the connections among all the elements.

This pane helps us understand how Vega is processing the data and transforming it step by step. When our chart doesn’t behave as expected, this is the place to look.

In this series of posts, I will give a lot of examples to help you learn better. You can see the code for a particular chart by clicking on the three dots in the top right corner and selecting ‘Open in Vega Editor’. It will open the online editor in a new tab with the code to create the visual. Similarly, you can select ‘View Source’ to see the JSON code only.

This feature makes it very convenient to learn from others’ charts or to debug your own.

Try this out with the following chart:

Editor in Deneb

If you want to use Vega inside Power BI, you will need to import Deneb into your report. You can learn about Deneb and how to import it from its official website. The code editor in Deneb looks like this:

It is quite similar to the online editor. The only thing missing here is the DATAFLOW VIEWER. There are some other minor differences, which I will point out when necessary.

One nice thing about Deneb is that it integrates directly with your Power BI dataset. So instead of hardcoding data like we do in the online editor, we can work with dynamic data that’s already in our report.

For us, the most important pane is the Data pane. As we create more and more complex visuals and want to make our charts interactive, we need to make use of the Data pane quite frequently. It helps us verify what data is actually available to the visual and how it’s structured.

Explore the editors to get familiar with the different components. Don’t worry if some parts seem overwhelming at first—it will make sense as we go along. From the next post, we will start creating the visuals. Stay tuned!

Have you ever looked at a Power BI report or dashboard and wondered how some of the visualizations were created? With Power BI’s continuous advancements, many complex visualizations can now be built using native charts, conditional formatting, and DAX measures. However, there are still some charts that simply can’t be created using built-in visuals.

Take, for example, the following chart taken from the Vega example gallery.

Another example is the event calendar below that I created for one of my clients.

While Power BI does offer many custom visuals through the App Store, some are paid while others are free. Among the free ones, Deneb stands out as, in my opinion, the best. Deneb is certified by Microsoft, meaning that it doesn’t access external services or resources and can be exported to PDF or displayed in emails. Pretty cool, right?

Now, plenty of resources explain what Deneb is and how it works, so I won’t go into that. Instead, I want to focus on the language Deneb uses to create these stunning visuals: Vega and Vega-Lite. Think of them as twin sisters—except Vega is more complex to grasp but also offers more customizations. In this series of posts, we will learn about Vega.

What is Vega?

Let’s take a look at the definition of Vega from its official website:

Vega is a visualization grammar, a declarative language for creating, saving, and sharing interactive visualization designs. With Vega, you can describe the visual appearance and interactive behavior of a visualization in a JSON format, and generate web-based views using Canvas or SVG.

Simply put, Vega is a structured way of describing visualizations, much like grammar in a language. Just as grammar defines the rules for adjectives, adverbs, and prepositions, Vega provides a defined set of rules for building charts. Both Vega and Vega-Lite use JSON syntax, which consists of key-value pairs like: "name": "Nazmul" or "date": "2024-08-05". This means that every visualization you create in Vega and Vega-Lite is simply a structured JSON object describing the chart.

Understanding Vega the Right Way

Now comes the real challenge: How do we make sense of this language in a logical and intuitive way?

Surely, learning English grammar wasn’t easy. And unfortunately, most existing resources don’t explain Vega’s syntax in a way that’s beginner-friendly. The Official Documentation is comprehensive, but if you jump straight into it—like I did—you’ll feel like you’re reading Martian! So, Should You Give Up?

Absolutely not! That’s where this series comes in.

In this series of posts, I’ll break down the logical structure of Vega in an easy-to-understand way. I’ll not only explain the concepts but also provide plenty of examples to reinforce them.

What You Should Know Before We Start

1. Progressive Learning – Each post builds on the previous ones. I’ll assume you’ve read the earlier posts and won’t repeat concepts unnecessarily. So, make sure you follow along from the beginning to get the most out of this series.

2. Power BI vs. Vega – Vega is a standalone visualization language, while Deneb is its Power BI implementation. There are some Power BI-specific features in Deneb that don’t exist in standard Vega. For now, we’ll mainly focus Vega, and once we understand it well, we’ll explore how it works inside Power BI.

What’s Next?

In the next post, we’ll explore the online Vega editor and the code editor of Deneb. These tools have some features that will help us understand and debug our code easily.

So, are you ready to master Vega? Let’s get started!

SQL is a powerful tool for querying and managing data, but like any skill, it takes practice to master. This holiday season, I challenged myself to complete 24 Days of SQL Advent Calendar Challenge, a series of SQL problems designed to test and improve my skills. Each challenge presented unique scenarios that required creativity, logic, and a deep understanding of SQL concepts.

In this post, I’ll share my solutions to the challenges along with explanations for how I approached each problem. My goal is to provide clear and concise answers while offering insights into the thought process behind the queries. Whether you’re a beginner looking to learn or an experienced SQL user seeking new ideas, I hope you find this post helpful and inspiring.

About the Challenge

This challenge was created by Dawn Choo, a renowned data scientist with over 90,000 followers on LinkedIn. Be sure to follow her for some fantastic resources and insights!

Unfortunately, the challenge was closed in January, so it’s no longer available for practice.

Challenge - 01

Question: A ski resort company want to know which customers rented ski equipment for more than one type of activity (e.g., skiing and snowboarding). List the customer names and the number of distinct activities they rented equipment for.

Answer:

SELECT
    customer_name,
    COUNT(DISTINCT activity) AS dist_activity
FROM rentals
GROUP BY customer_name
HAVING dist_activity > 1;

Comment: This is a straight forward question. The question is to get the distinct count of the activities per customer. So, I grouped the results by customer name and then filtered the result to get the customers with more than one distinct activities.

Challenge - 02

Question: Santa wants to know which gifts weigh more than 1 kg. Can you list them?

Answer:

SELECT DISTINCT gift_name
FROM gifts
WHERE weight_kg > 1;

Comment: Well, isn’t this an easy one!

Challenge - 03

Question: You’re trying to identify the most calorie-packed candies to avoid during your holiday binge. Write a query to rank candies based on their calorie count within each category. Include the candy name, category, calories, and rank (rank_in_category) within the category.

Answer:

SELECT 
    candy_name, 
    candy_category, 
    calories, 
    RANK() OVER(
      PARTITION BY candy_category 
      ORDER BY calories
    ) AS rank_in_category 
FROM 
  candy_nutrition;

Comment: This one is interesting! The question tells us to rank the candies within each category. So I created windows/ partitions for each category and within that window applied the rank() function and then sorted the results by calories.

Challenge - 04

Question: You’re planning your next ski vacation and want to find the best regions with heavy snowfall. Given the tables resorts and snowfall, find the average snowfall for each region and sort the regions in descending order of average snowfall. Return the columns region and average_snowfall.

Answer:

SELECT
    ski.region,
    AVG(snow.snowfall_inches) AS average_snowfall
FROM ski_resorts AS ski
    LEFT JOIN snowfall AS snow
        USING(resort_id)
GROUP BY ski.region
ORDER BY average_snowfall DESC; 

Comment: USING is a useful keyword for joining two tables when the column names used for the join are the same.

Challenge - 05

Question: This year, we’re celebrating Christmas in the Southern Hemisphere! Which beaches are expected to have temperatures above 30°C on Christmas Day?

Answer:

SELECT 
    beach_name,
    expected_temperature_c
FROM beach_temperature_predictions
WHERE expected_temperature_c > 30
    AND date = "2024-12-25"; 

Challenge - 06

Question: Scientists are tracking polar bears across the Arctic to monitor their migration patterns and caloric intake. Write a query to find the top 3 polar bears that have traveled the longest total distance in December 2024. Include their bear_id, bear_name, and total_distance_traveled in the results.

Answer:

SELECT
    pb.bear_id,
    pb.bear_name,
    SUM(tr.distance_km) AS total_distance_traveled
FROM polar_bears AS pb
    INNER JOIN tracking AS tr
        ON pb.bear_id = tr.bear_id
WHERE strftime('%m', date) = "12"   -- BETWEEN also works.
    AND strftime('%Y', date) = "2024"
GROUP BY
    pb.bear_id,
    pb.bear_name
ORDER BY total_distance_traveled DESC
LIMIT 3;

Comment: The strftime function in SQLite is a powerful tool for formatting date and time values. It allows you to extract specific parts of a date or time, or to represent them in a variety of formats. This function isn’t available in MySQL, and because I learned SQL with MySQL, I was unaware of it. I struggled a bit to solve the problem, but I eventually learned the function and found a solution.

Challenge - 07

Question: The owner of a winter market wants to know which vendors have generated the highest revenue overall. For each vendor, calculate the total revenue for all their items and return a list of the top 2 vendors by total revenue. Include the vendor_name and total_revenue in your results.

Answer:

SELECT
    v.vendor_name,
    SUM(
        s.quantity_sold * s.price_per_unit
        ) AS total_revenue
FROM vendors AS v
    LEFT JOIN sales AS s
        USING(vendor_id)    -- Same name in both tables.
GROUP BY v.vendor_name
ORDER BY total_revenue DESC
LIMIT 2;

Challenge - 08

Question: You are managing inventory in Santa’s workshop. Which gifts are meant for “good” recipients? List the gift name and its weight.

Answer:

SELECT
    gift_name,
    weight_kg
FROM gifts
WHERE recipient_type = "good";

Challenge - 09

Question: A community is hosting a series of festive feasts, and they want to ensure a balanced menu. Write a query to identify the top 3 most calorie-dense dishes (calories per gram) served for each event. Include the dish_name, event_name, and the calculated calorie density in your results.

Answer:

WITH ranked_dishes AS (
    SELECT
        m.dish_name,
        e.event_name,
        CAST(m.calories AS float) / m.weight_g AS cal_density,
        ROW_NUMBER() OVER (
            PARTITION BY e.event_name
            ORDER BY CAST(m.calories AS float) / m.weight_g DESC
            ) AS rank
    FROM events AS e
        LEFT JOIN menu AS m
            USING(event_id)
)
SELECT
    dish_name,
    event_name,
    cal_density
FROM ranked_dishes
WHERE rank <= 3
ORDER BY
    event_name,
    cal_density DESC;

Comment: The CAST function here was necessary to convert the data into decimals. I was getting wrong results without it for some reason. Any idea?

Challenge - 10

Question: You are tracking your friends’ New Year’s resolution progress. Write a query to calculate the following for each friend: number of resolutions they made, number of resolutions they completed, and success percentage (% of resolutions completed) and a success category based on the success percentage:

• Green: If success percentage is greater than 75%.
• Yellow: If success percentage is between 50% and 75% (inclusive).
• Red: If success percentage is less than 50%.

Answer:

WITH temp AS    -- First CTE for grouping.
    (
    SELECT
        friend_name,
        COUNT(resolution) AS res_made,
        SUM(is_completed) AS res_completed
    FROM resolutions
    GROUP BY friend_name
    ),
cte AS          -- Second CTE for success percentage.
    (
    SELECT *,
        (CAST(res_completed AS float) / res_made) * 100 AS per_success
    FROM temp
    )
SELECT *,
    CASE
        WHEN per_success < 50 THEN "Red"
        WHEN per_success <= 75 THEN "Yellow"
        WHEN per_success > 75 THEN "Green"
    END AS success_cat
FROM cte;

Challenge - 11

Question: You are preparing holiday gifts for your family. Who in the family_members table are celebrating their birthdays in December 2024? List their name and birthday.

Answer:

SELECT
    name,
    birthday
FROM family_members
WHERE strftime('%m', birthday) = "12"
    AND strftime('%Y', birthday) = "2024";

Challenge - 12

Question: A collector wants to identify the top 3 snow globes with the highest number of figurines. Write a query to rank them and include their globe_name, number of figurines, and material.

Answer:

SELECT
    gl.globe_name,
    COUNT(fg.figurine_id) AS num_figurines,
    gl.material
FROM snow_globes AS gl
    LEFT JOIN figurines AS fg
        USING(globe_id)
GROUP BY gl.globe_name
ORDER BY num_figurines DESC
LIMIT 3;

Challenge - 13

Question: We need to make sure Santa’s sleigh is properly balanced. Find the total weight of gifts for each recipient.

Answer:

SELECT
    recipient,
    SUM(weight_kg) AS total_weight
FROM gifts
GROUP BY recipient;

Challenge - 14

Question: Which ski resorts had snowfall greater than 50 inches?

Answer:

SELECT resort_name
FROM snowfall
WHERE snowfall_inches > 50;

Challenge - 15

Question: A family reunion is being planned, and the organizer wants to identify the three family members with the most children. Write a query to calculate the total number of children for each parent and rank them. Include the parent’s name and their total number of children in the result.

Answer:

SELECT
    f.name,
    COUNT(r.child_id) AS total_children
FROM family_members AS f
    INNER JOIN parent_child_relationships AS r
        ON f.member_id = r.parent_id
GROUP BY f.name
ORDER BY total_children DESC
LIMIT 3;

Comment: Aliasing table names makes SQL queries shorter, more readable, and easier to maintain, especially when dealing with long table names or when joining multiple tables.

Challenge - 16

Question: As the owner of a candy store, you want to understand which of your products are selling best. Write a query to calculate the total revenue generated from each candy category.

Answer:

SELECT
    category,
    SUM(
        quantity_sold * price_per_unit
    ) AS total_revenue
FROM candy_sales
GROUP BY category;

Challenge - 17

Question: The Grinch is planning out his pranks for this holiday season. Which pranks have a difficulty level of “Advanced” or “Expert”? List the prank name and location (both in descending order).

Answer:

SELECT
    prank_name,
    location
FROM grinch_pranks
WHERE difficulty IN ("Advanced", "Expert")
ORDER BY
    prank_name DESC,
    location DESC;

Challenge - 18

Question: A travel agency is promoting activities for a “Summer Christmas” party. They want to identify the top 2 activities based on the average rating. Write a query to rank the activities by average rating.

Answer:

SELECT
    a.activity_name,
    AVG(r.rating) AS average_rating
FROM activities AS a
    LEFT JOIN activity_ratings AS r
        USING(activity_id)
GROUP BY a.activity_name
ORDER BY average_rating DESC
LIMIT 2;

Challenge - 19

Question: Scientists are studying the diets of polar bears. Write a query to find the maximum amount of food (in kilograms) consumed by each polar bear in a single meal December 2024. Include the bear_name and biggest_meal_kg, and sort the results in descending order of largest meal consumed.

Answer:

SELECT
    b.bear_name,
    MAX(m.food_weight_kg) AS biggest_meal_kg
FROM polar_bears AS b
    INNER JOIN meal_log AS m
        USING(bear_id)
WHERE m.date BETWEEN
    "2024-12-01" AND "2024-12-31"
GROUP BY bear_name
ORDER BY biggest_meal_kg DESC;

Challenge - 20

Question: We are looking for cheap gifts at the market. Which vendors are selling items priced below $10? List the unique (i.e. remove duplicates) vendor names.

Answer:

SELECT DISTINCT vendor_name
FROM vendors
    INNER JOIN item_prices
        USING(vendor_id)
WHERE price_usd < 10;

Challenge - 21

Question: Santa needs to optimize his sleigh for Christmas deliveries. Write a query to calculate the total weight of gifts for each recipient type (good or naughty) and determine what percentage of the total weight is allocated to each type. Include the recipient_type, total_weight, and weight_percentage in the result.

Answer:

SELECT
    recipient_type,
    SUM(weight_kg) AS total_weight,
    (
        SUM(weight_kg) * 1.0 / SUM(weight_kg) OVER()
    ) * 100 AS weight_percentage
FROM gifts
GROUP BY recipient_type;

Challenge - 22

Question: We are hosting a gift party and need to ensure every guest receives a gift. Using the guests and guest_gifts tables, write a query to identify the guest(s) who have not been assigned a gift (i.e. they are not listed in the guest_gifts table).

Answer:

SELECT guest_name
FROM guests
    LEFT JOIN guest_gifts
        USING(guest_id)
WHERE gift_id IS NULL;

Challenge - 23

Question: The Grinch tracked his weight every day in December to analyze how it changed daily. Write a query to return the weight change (in pounds) for each day, calculated as the difference from the previous day’s weight.

Answer:

SELECT
    day_of_month,
    weight - LAG(weight, 1) OVER(
        ORDER BY day_of_month
        ) AS weight_change
FROM grinch_weight_log;

Comment: The LAG function in SQL is a window function that allows you to access data from a previous row within the same result set. It’s incredibly useful for comparing values in the current row with values in a preceding row, often for tasks like calculating differences, trends, or moving averages.

Challenge - 24

Question: Santa is tracking how many presents he delivers each night leading up to Christmas. He wants a running total to see how many gifts have been delivered so far on any given night. Using the deliveries table, calculate the cumulative sum of gifts delivered, ordered by the delivery date.

Answer:

SELECT
    delivery_date,
    SUM(gifts_delivered) OVER(
        ORDER BY delivery_date
    ) AS sum_gifts_delivered
FROM deliveries;

Conclusion

Finally, this challenge was such a rewarding experience! It didn’t just sharpen my SQL skills—it also reminded me how fun and engaging problem-solving can be.

As a VBA developer, I’ve come to realize that maintaining clean, consistent, and understandable code is critical, especially for projects that grow over time or involve collaboration. One of the simplest yet most effective ways to achieve this is by using a clear naming convention for variables, procedures, and objects in VBA.

In this post, I’ll share the naming convention I follow in my VBA projects. It’s simple, logical, and ensures that anyone reading the code (including future me 🤔!) can easily understand its purpose.

What are Naming Conventions?

Naming conventions are like roadmaps 🛣️ for your code. They provide a clear, consistent way of labeling variables, functions, and other elements so that anyone reading your code can quickly understand its purpose. Imagine trying to navigate a city where street signs are missing or randomly labeled—it would be frustrating and time-consuming. The same applies to coding. When names are clear and follow a pattern, the code becomes easier to read, debug, and extend.

In VBA, where you often deal with objects like worksheets, ranges, and user forms, a good naming convention is especially valuable. It helps you quickly identify what a variable represents or what a procedure does, reducing the chances of errors and making your projects much easier to manage over time.

Why Naming Conventions Matter

Naming conventions aren’t set in stone, and they’re definitely not a rule you must follow to write code. But here’s the thing—they make life so much easier. Think of them as labels on jars in your kitchen. Sure, you could leave them unlabeled, but having “Sugar” and “Salt” clearly marked saves you from awkward mistakes.

In coding, naming conventions serve a similar purpose. They help you quickly understand what each variable, function, or object does without needing to decipher it every time. For VBA, where you’re often working with Excel objects, a clear naming convention can make your code feel less like a maze and more like a well-organized toolkit. While not obligatory, it’s a small effort that pays off big when debugging, revisiting old projects, or collaborating with others.

My Naming Conventions

When it comes to naming conventions, I like to keep things practical and straightforward. The goal isn’t to make the names overly complex or follow rigid rules but to create a structure that’s easy to remember and intuitive to use. My approach ensures that variables, procedures, and objects are self-explanatory, helping me (and anyone else reading the code) quickly understand their purpose without digging too deep. Here’s how I structure my naming conventions:

1. Variables

I use camel 🐫 case along with certain prefixes to make the purpose clear at a glance. If you’re unfamiliar, camel case is a style where the first word is lowercase, and each subsequent word starts with an uppercase letter—like this: myVariableName. It keeps names compact and readable.

For variables, I add the prefix var before all variable names to immediately identify them as variables. This approach ensures consistency and prevents any confusion with object names or other identifiers. As for the actual name, I try to keep it short yet descriptive. For example:

Sub subVariablesEx()
    'Declare Variables:
    Dim varUserName As String
    Dim varIsEmpty As Boolean
    Dim varTotalCost As Double
    Dim varPricesArr() As Variant
    ...
End Sub

2. Procedures & Functions

For procedures and functions, I like to keep things straightforward by using prefixes that immediately distinguish between the two. I prefix all my procedures with sub and my functions with fun. This makes it clear at a glance whether a block of code performs an action (sub) or returns a value (fun). Additionally, I name my functions in all caps after the prefix, like funCALC_TOTAL(), to make them stand out. For example, a procedure might be named subUpdateDashboard, while a function could be funSQUARE_ROOT(). This approach keeps my code organized and makes it easier to understand the purpose of each routine. Example:

'PROCEDURE NAME EXAMPLE:
Sub subEditEntry()    
    'Necessary Codes 
End Sub

'FUNCTION NAME EXAMPLE:
Function funSTD()
    'Necessary Calculations    
End Function

3. Constants

When it comes to constants, I like to keep things bold and obvious. I use all uppercase letters with underscores to separate words, which makes them stand out from the rest of the code. For instance, PI, MY_CONSTANT, or PLANK_CONST are some examples of how I name my constants. This style not only keeps the code clean but also acts as a clear indicator that these values are fixed and not meant to be altered. It’s a simple yet effective way to avoid confusion.

4. Modules

If you’ve read this far, you might assume I use the prefix mod for module names. Well, I don’t—mainly because module names are rarely used inside the code. Instead, I stick with camel case, but I capitalize the first letter as well. For example, I name my modules DataEntry, EditWorkSheet, DataCleaning, and so on. This keeps the names simple, clean, and easy to recognize when navigating through the project.

5. Sheets

When working with sheets, I like to keep their names both functional and easy to identify. I use the prefix sht to make it immediately clear that I’m referencing a worksheet, followed by a name that reflects its purpose. For instance, shtDashboard is for the dashboard, shtTransactions handles transaction data, and shtPivotTables stores pivot tables. This way, even in a large project with multiple sheets, I know exactly which one I’m working with without any guesswork. It’s all about clarity and avoiding unnecessary confusion.

6. Object Names

Naming objects like UserForms and controls requires a method that ensures clarity and distinction. I use specific prefixes to indicate the type of object, making it effortless to understand its role in the project. Here’s a quick overview of the prefixes I use:

Wrap-up Example

To wrap things up, here’s a practical example that incorporates many of the naming conventions discussed. This code snippet shows how different types of variables, procedures, and objects work together in a simple VBA project. You’ll see camel case for variables, prefixes for procedures and functions, and uppercase for constants. By following these conventions, the code is not only organized but also much easier to read and maintain.

Sub subCalculateInvoice()
    ' Declare Variables:
    Dim varProductName As String
    Dim varQuantity As Integer
    Dim varUnitPrice As Double
    Dim varTotalPrice As Double
    Dim varInvoiceData() As Variant
    
    ' Constants:
    Const TAX_RATE As Double = 0.07
    
    ' Initialize Variables:
    varProductName = "Laptop"
    varQuantity = 5
    varUnitPrice = 1000.0
    
    ' Calculate Total:
    varTotalPrice = funCALCULATE_TOTAL(varQuantity, varUnitPrice)
    
    ' Output Data to Worksheet:
    shtInvoice.Cells(1, 1).Value = varProductName
    shtInvoice.Cells(1, 2).Value = varQuantity
    shtInvoice.Cells(1, 3).Value = varTotalPrice
End Sub

Function funCALCULATE_TOTAL(varQty As Integer, varPrice As Double) As Double
    funCALCULATE_TOTAL = varQty * varPrice * (1 + TAX_RATE)
End Function

Common Pitfalls to Avoid

While naming conventions are essential, there are a few common pitfalls that you should avoid to keep your code clean and consistent. One mistake is using vague or overly generic names for variables and functions. For example, names like varData or funProcess don’t give enough context about what the variable or function is doing. Instead, aim for names that are descriptive and specific to the task, such as varCustomerName or funCALCULATE_TOTAL.

Another pitfall is inconsistency in naming styles. Switching between camel case, snake case, or using random prefixes can confuse you or others who need to read your code later. For instance, mixing varTotalCost with total_cost or VarProductName with productname creates unnecessary complexity. Stick to one naming convention and apply it consistently throughout your project. Finally, be careful with abbreviations; while abbreviations can make names shorter, they can also make your code harder to understand. Always prioritize clarity over brevity.

Conclusion

In the end, a solid naming convention can make a world of difference when working with VBA code. It’s all about creating an organized, consistent structure that allows you (and others) to navigate the code with ease. Whether you’re working solo on a project or collaborating with a team, following clear and intuitive naming practices saves time, reduces errors, and makes your code much easier to maintain.

I’ve found that keeping things simple yet descriptive, with prefixes for easy identification, works best for me. Of course, naming conventions can vary from one developer to another, and there’s no one-size-fits-all approach. But if you’re looking for a way to make your VBA projects cleaner and more understandable, I hope this post gave you some useful ideas!

What naming conventions do you follow in your VBA projects? I’d love to hear your thoughts or suggestions in the comments below! Let’s keep the conversation going and learn from each other.