Can we have some shorter debug.print shorter methods?

Hi,

…this is just a ramblings/idea from a beginner in zig and systems programming in general.

From a person that only a few days started using zig, still half way through zigglings, I only have one complain.

can we pleassseee make debug print statements shorter? Things like std.debug.print() dont help at all.

That is probably one of the things developers will type the most… and for some reason was decided to make it a long thing to type. Having it has @debug() or @dbg() would help. Cant we just make it shorter? or having an help macro that does that?

Apologise for the ramblings and thanks for the language.

2 Likes

If you would like to have a shorthand in your files you can do something like the following:

const std = @import("std");
const dbg = std.debug.print;

pub fn main() void {
    dbg("Hello, World!\n", .{});
}
3 Likes

The issue with it, though, is that you wouldn’t normally want debug print statements polluting your code, so you add and remove them all the time, but this alias will always have to be there, in every file, plus, everyone will tend to make his own name for this alias harming Zig code consistency => readability across codebases, which feels redundant and kinda does bring about the question of why not make it a compiler builtin, after all.

1 Like

thanks for the replies.

@permutationlock
I dont like the approach of const dbg = std.debug.print;, because that makes someone else search the code to find where does dbg comes from. Thats why I mention to come from zig itself.

@tensorush I understand and agree about the poluting the code part, but is a necessary evil to have them there while your coding, the alternative is todo step-by-step debugging, which I prefer but dont think is possible with zig at the moment.

Thats one of the reasons why in JS world when you minify the code, they can remove comments and console.log lines. And that should be a compile or pre-compile job todo it (or at least to help the developer)

The reason why I mention it, is if we have to type that thing thousand times a day… why not make it easier… specially since in terms of character count… most times we are trying to print somthing smaller thant the actually print statement, And we have to write a whole sentence, just to dump a variable. And you help me even more by saying “wouldn’t normally want debug print statements polluting your code”, typing all of that to delete after :man_shrugging:

std.debug.print("{}", .{age});
1 Like

I think this is not really a language concern, but more of a tooling issue.
I think a little more convenience for debug printing is not worth adding more compiler builtin functions to the list, a list which is already overwhelming for newcomers.
In java for example, many IDEs have a shortcut for writing System.out.println.

5 Likes

debug.print is intended to be removed soon. It’s not a proper logging tool, as it’s uncached. Therefore, you write it to do some printf debugging, and, at the end of a session, you’re expected to clean it up, so other people won’t have to search for the symbol. Since it’s short term, there’s no problem in aliasing it.
Proper logging, even for debugging purposes, should be done with std.debug.log. Since you’ll probably want to keep these in the final code, and it will be a standard thing in the whole project, I don’t think it’s a problem to create a file with a shortcut like const log = std.debug.log, and the members of the team just import this file.

This is a tooling issue, and it’s one that is relatively easy to solve in most IDEs by using keybindings, macros or code snippets. For example, in Visual Studio Code, you could add the snippet

{
    "std.debug.print": {
        "scope": "zig",
        "prefix": "dbg",
        "body": [
            "std.debug.print(\"$1\\n\", .{$2});"
        ],
        "description": "Print a debug message to stderr."
    }
}

which will let you type dbg, hit Tab and have it auto complete all the boiler plate with conveniently placed tab stops.

Deleting the print statements can be just as simple; most editors have a “delete current line” keybinding (in VS Code on Windows it’s Ctrl+Shift+K by default), so you can just navigate your cursor to the line with the print statement and hit those keys.

Compiler builtins are generally meant to solve problems that can’t be solved (efficiently) in user code. For example, @compileLog (which works like a std.debug.print statement but at compile time) is a builtin because comptime (by design) can’t access system resources like standard output streams. A @debug builtin would be completely superfluous.

6 Likes

I think you’re trying to say, “when you use std.debug.print, you should intend on removing the print call soon afterwards,” but it can also be read as “std.debug.print will be removed from the standard library soon” (which isn’t true AFAIK). Just want to clarify which you meant.

4 Likes

I’m using Neovim with ZLS and when I type pri I get a snippet suggestion that expands out to the full std.debug.print("", .{}); with tab moving from the format string to the args too. Very nice.

1 Like

I initially understood it like if it was going to be removed from std too. Almost had a heart attack there. lol

1 Like

lol, me too

1 Like

If you are using vscode with zls put your cursor on dbg at the call site and press F12. vscode will jump to exact location where it is defined and you will know what it is.

I think that Zig stroke a golden balance here. If you want verbosity and easy grep use explicit std.debug.print; want a shortcut – define dbg constant. To each their own :slight_smile:

Agree with all of that, if people play around with nice editor/ides. I’ve seen people using from Notepad to Nano, where none of those things exists.

Time to upgrade the tooling. One cannot design a new language with stone-age tools in mind.