Why remove redstone dust from my command block contraptions?

Your friends are right, redstone dust is evil and it should be avoided at all costs when making command block contraptions. Redstone dust does cause lag and it can be unpredictable. There's a nice blog post explaining why this is the case, but suffice it to say that pretty much every expert map maker limits their use of redstone dust to very specific edge cases, and it's never used on high frequency lines.

So, what should you be using instead? For a clock, use a 20Hz clock. Better yet, start using 1.9 and use repeating command blocks. For turning on a redstone device, use setblock to place a redstone block or torch at the activation point. This is especially useful for when your command blocks are far away from any redstone contraption (as they should be).

The only actual redstone that you should have in your command block contraption is redstone blocks (for activating the command blocks), comparators (for testing for a success on a command block, but even these aren't necessary; use the stats command instead), and on the extremely rare occasion, a repeater. Also, sometimes a button or switch, but that should be given. But that's for 1.8, and in 1.9, the entire command block game changes. 1.9 will allow you to remove even more redstone, to the point where you don't need any (not even a switch or button) to do something useful. Again, you'll need to be able to interface with redstone devices from time to time, but as I said above, that should be done with something like a setblock command.

In the end, you should do your best to keep your redstone stuff and your command block stuff separated. There was a time when this wasn't possible, but that was ages and ages ago, when the command block was first introduced. New commands made it possible to separate your redstone and command blocks, and with the new features in 1.9, this becomes even easier to do; you no longer need to think about how to build a 20Hz clock, execution order is trivialized to block placement, and conditional execution becomes built in. Redstone dust is great for making interesting contraptions in survival, but it has no place in your creative mode command blocks.

---

Minecraft v1.13 has changed the game again. Now, you don't even need command blocks in your world, you can use functions instead and tag them to run either every tick, or when the world loads. (Admittedly, some of this was available in earlier versions, but 1.13 was a major update to commands which made for a compelling reason to move as much as possible to functions.)

Command blocks will still be necessary in some very narrow circumstances (conditional execution in some cases is still difficult using just functions), but other than prototyping, I would recommend using functions instead of command blocks for most purposes. There's loads of reasons for doing this, but among the top reasons I see are:

• Code reuse and deduplication
• Maintainability
• Ease of reading

Something to keep in mind, though, is that a number of commands have been removed/replaced in 1.13, such as the stats command mentioned above (the new version as part of the execute command is actually a lot easier and more intuitive now). The power of commands has grown substantially since the command block was introduced in 1.4, but redstone has only seen incremental improvements. Most of the improvements in redstone were with the addition of blocks aimed at eliminating the need for BUD switches (those blocks being daylight detector and observer blocks). Other than that, there isn't much in the way of new redstone, whereas commands have been evolving almost with every release.

Here is my own take on this, including more reasons and more "best practices".

Why should you only use command blocks or functions, not redstone?

• Firstly, you don't need to use redstone. Once you know how to do things the "proper" way, it's actually usually easier to do everything like that.
  As a basic example, writing execute if entity @e[type=sheep] run say hi into one command block is easier than using one command block with execute if entity @e[type=sheep], a comparator and another command block with say hi and then ensuring that the comparator turns off before you run the commands a second time.
  The method with two command blocks was how it was done until 1.7.10 (in 2014) with /testfor and some people still think of commands as this separate system of "check for something or do something, but not both in one command". That has however changed over time, especially with 1.13. Until 1.12.2, a few edge cases were left in which you needed redstone (or it was at least extremely complicated without), now you never need it.
• Preserving execution context and improving reliability: Long ago, it was common to do things like /testfor @p[c=10] to check for a player in a radius of 10 blocks and then, connected with a comparator, /tp @p <coords>. This has the issue that the closest player to that second command block might very well be someone else. There were also cases in which the condition wasn't properly matched and you accidentally teleported the completely wrong person. And to make sure that you don't, you have to enter all the selector arguments twice. The condition could also change during the comparator delay.
  With proper use of the 1.13+ commands, you can combine check and action like this: /execute as @p[distance=..10] run tp @s <coords>
  Here you have re-used the execution context of "act as the closest player within 10 blocks" for the /tp command and it was applied instantly. _{^{(Yes, I realise that this easy example could work without /execute, but that does not work for many other cases.)}}
  Using functions, you can even keep an execution context around for multiple commands, no matter what you do in the meantime. That way you can easily do a bunch of stuff on the same condition or at the same location, even if e.g. what originally referenced that position is long gone.
• Tamper-proofing: Survival players can freely interact with redstone, they can break it, place new redstone (a repeater can even activate things through a bedrock wall), change repeater settings and so on. Water or lava can also accidentally flush away your redstone, TNT could blow it up and so on. Even if you put your command blocks and redstone into a bedrock box, smart players could get in using for example Nether portals or chorus fruit.
  All of this does not apply if you use only command blocks. Even if you gave a Survival player a command block item with a pre-written command inside, they could not place it down. Minecraft has many security precautions to prevent Survival players from interacting with command blocks in any way.
  If you use functions, you're even safer, because not even Creative players with access to commands can change them, only people who have access to the server files.
• Sharing and backups: Structure blocks have made it easier to copy areas of one world into another or to backup areas, but that is easier if you don't also need to consider the floor for redstone and all the additional space that it takes. It's also quite a bit of effort to get an area into a structure file. If you use functions, you have a single folder or ZIP file that you can copy anywhere, so you can create backups in a second or share the file over the internet. The receiver can then just put the file into the right location, (re-)start Minecraft or run /reload and the setup is done. If you want to make your contraption available to people who don't have access to the server files (like on Realms), you can use an automatic one-command creator like the one linked here, if you have all your commands in one chain of command blocks. This does not work if redstone is involved.
• Recursion: Functions allow recursion and therefore loops, meaning that you can execute as many repetitions of commands instantly as you want. That is useful is many more ways that you might think, for example you can do raycasting without a dummy entity. It is possible to do this with command blocks, as seen in this video by Slicedlime, but that requires a bunch of extra work and space.
• Server lag and bugs: https://bugs.mojang.com/browse/MC-81098 Redstone dust turning on and off causes a lot of block updates. So much even that a big area of redstone dust is the most common way to build "lag machines" and has been for years. Apart from that, repeating command blocks and even more so functions are specially optimised for exactly the type of things that they're used for, but redstone is not.
  There are also various bugs with redstone. Those should usually not matter much if you just use a single comparator or a few repeaters, but they could. Especially the barely predictable update order of redstone could cause issues.
• Easier editing: In a function file, you see all (or a lot of) commands at a glance, so you don't need to open and close the GUI of tens of command blocks and move around in the world to finally find what you are looking for. You can also use all the features of a text editor, like search+replace, undo, etc.
  If you want to insert another command in between two in a command block chain, the easiest is to figure out the coordinates of the first and the last block to move and the new position, use /clone … replace move with those (doing that wrong can overwrite things you wanted to keep), place a new command block in between and open its GUI. In a function, you simply press Enter.
• Chunk loading: If you want commands to always run, you would need to place the command blocks in the spawn chunks or in an area that you keep loaded using /forceload. The first option takes space away from the most important place in the world, the second causes additional lag to keep an area loaded that you don't care about anyway. If you then also use redstone with your command blocks, you can run into issues with that redstone reacting differently than expected when chunks load in a different order, with different timing, etc. This is especially a problem in 1.14 and above.

How to do it better?

• If you can use functions, you should. The barrier to entry is admittedly higher for them, because you need to create a datapack first. My solution for that is to always start at a datapack skeleton I have created long ago and since then copied very often as a starting point for my datapacks. Here you can download such a dummy datapack: https://drive.google.com/file/d/15Gzp4dqyCfbQ_iGObfwKApxft6TLX8Zt
  Simply put this datapack into saves/<world>/datapacks in your Minecraft folder and open that world. Now the server spams "empty" every tick, because there is a function tag that executes a function every tick, whose content is only "say empty". You can remove the function from that tag or add more, you can edit the function, create new ones, etc. The folder structure is already there, as well as a valid pack.mcmeta file.
• If you can not use functions, you should use one repeating command block, followed by chain command blocks. They act very similarly to a function. If you use multiple independent repeating chains, the order in which they are executed related to each other can be unpredictable.
  Of course you can also use an impulse command block with a button on it, there's nothing wrong with using such a redstone component for it if you intend to manually use it anyway, it's just the use of the old "fill clocks" or regular redstone clocks, comparators instead of conditional command blocks and so on that is discouraged.

FAQ

How to use conditional command blocks in function?

You can use /execute store success to check whether a command succeeded, like this:

/execute store success score #dummy scoreboard_name run …

That command stores the success count of the command after "run" in the scoreboard named "scoreboard_name" for the fake player "#dummy". That fake player name starts with a hash, so it will not show up in the sidebar when you set a scoreboard to be shown there.

You can then execute a command conditionally on that:

/execute if score #dummy scoreboard_name matches 1.. run …

This command will be executed only if the score is 1 or higher, so only if the first command succeeded. The reason for also checking for higher numbers is that /execute store success might in some cases return more than 1. This seems to currently be broken, but once that is fixed, it's good to already be prepared.

How to delay or slowly loop commands without repeaters?

I have a separate Q&A about that already: How to delay or slowly loop commands?

The easiest part of that answer is, if you have access to functions, to use /schedule (archive).

Further information

Slicedlime has excellent commands and mapmaking tutorial series, most of which is still true, even over 5 years later:
https://www.youtube.com/playlist?list=PL4ZS2guXqa_g1NI8t0djmrRtOaZ6brg46
https://www.youtube.com/playlist?list=PL4ZS2guXqa_j854EGAO3NSqiaaxMHQdSD
https://www.youtube.com/playlist?list=PL4ZS2guXqa_j1z9i74V8KavMLzG1yTxFq

Of course the command syntax has changed a lot in 1.13, so you should now mainly pay attention to the principles from those tutorials, not the exact commands.