Cuely

cuely

Full stack development is often likened to an intricate balancing act, where developers are expected to juggle multiple responsibilities across the frontend, backend, database, and beyond. As the definition of full stack development continues to evolve, so too does the approach to debugging. Full stack debugging is an essential skill for developers, as it involves tracking issues through multiple layers of an application, often navigating domains where one’s knowledge may only be cursory. In this blog post I aim to explore the nuances of full stack debugging, offering practical tips and insights for developers navigating the complex web of modern software development. Notice that this is an introductory post focusing mostly on the front end debugging aspects, in the following posts I will dig deeper into the less familiar capabilities in front end debugging. https://www.youtube.com/watch?v=mM8p2VrrEaE&embedable=true As a side note, if you like the content of this and the other posts in this series check out my Debugging book that covers this subject. If you have friends that are learning to code I'd appreciate a reference to my Java Basics book. If you want to get back to Java after a while check out my Java 8 to 21 book. Full Stack Development, A Shifting Definition The definition of full stack development is as fluid as the technology stacks themselves. Traditionally, full stack developers were defined as those who could work on both the frontend and backend of an application. However, as the industry evolves, this definition has expanded to include aspects of operations (OPS) and configuration. The modern full stack developer is expected to submit pull requests that cover all parts required to implement a feature—backend, database, frontend, and configuration. While this does not make them an expert in all these areas, it does require them to navigate across domains, often relying on domain experts for guidance. I've heard it said that full stack developers are: Jack of all trades, master of none. However, the full quote probably better represents the reality: Jack of all trades, master of none, but better than a master of one. The Full Stack Debugging Approach Just as full stack development involves working across various domains, full stack debugging requires a similar approach. A symptom of a bug may manifest in the frontend, but its root cause could lie deep within the backend or database layers. Full stack debugging is about tracing these issues through the layers and isolating them as quickly as possible. This is no easy task, especially when dealing with complex systems where multiple layers interact in unexpected ways. The key to successful full stack debugging lies in understanding how to track an issue through each layer of the stack and identifying common pitfalls that developers may encounter. Frontend Debugging: Tools and Techniques It isn't "Just Console.log" Frontend developers are often stereotyped as relying solely on Console.log for debugging. While this method is simple and effective for basic debugging tasks, it falls short when dealing with the complex challenges of modern web development. The complexity of frontend code has increased significantly, making advanced debugging tools not just useful, but necessary. Yet, despite the availability of powerful debugging tools, many developers continue to shy away from them, clinging to old habits. The Power of Developer Tools Modern web browsers come equipped with robust developer tools that offer a wide range of capabilities for debugging frontend issues. These tools, available in browsers like Chrome and Firefox, allow developers to inspect elements, view and edit HTML and CSS, monitor network activity, and much more. One of the most powerful, yet underutilized, features of these tools is the JavaScript debugger. The debugger allows developers to set breakpoints, step through code, and inspect the state of variables at different points in the execution. However, the complexity of frontend code, particularly when it has been obfuscated for performance reasons, can make debugging a challenging task. We can launch the browser tools on Firefox using this menu: On Chrome we can use this option: I prefer working with Firefox, I find their developer tools more convenient but both browsers have similar capabilities. Both have fantastic debuggers (as you can see with the Firefox debugger below), unfortunately many developers limit themselves to console printing instead of exploring this powerful tool. Tackling Code Obfuscation Code obfuscation is a common practice in frontend development, employed to protect proprietary code and reduce file sizes for better performance. However, obfuscation also makes the code difficult to read and debug. Fortunately, both Chrome and Firefox developer tools provide a feature to de-obfuscate code, making it more readable and easier to debug. By clicking the curly brackets button in the toolbar, developers can transform a single line of obfuscated code into a well-formed, debuggable file. Another important tool in the fight against obfuscation is the source map. Source maps are files that map obfuscated code back to its original source code, including comments. When generated and properly configured, source maps allow developers to debug the original code instead of the obfuscated version. In Chrome, this feature can be enabled by ensuring that "Enable JavaScript source maps" is checked in the developer tools settings. You can use code like this in the JavaScript file to point at the sourcemap file: //@sourceMappingURL=myfile.js.map For this to work in Chrome we need to ensure that "Enable JavaScript source maps" is checked in the settings. Last I checked it was on by default but it doesn't hurt to verify: Debugging Across Layers Isolating Issues Across the Stack In full stack development, issues often manifest in one layer but originate in another. For example, a frontend error might be caused by a misconfigured backend service or a database query that returns unexpected results. Isolating the root cause of these issues requires a methodical approach, starting from the symptom and working backward through the layers. A common strategy is to reproduce the issue in a controlled environment, such as a local development setup, where each layer of the stack can be tested individually. This helps to narrow down the potential sources of the problem. Once the issue has been isolated to a specific layer, developers can use the appropriate tools and techniques to diagnose and resolve it. The Importance of System-Level Debugging Full stack debugging is not limited to the application code. Often, issues arise from the surrounding environment, such as network configurations, third-party services, or hardware limitations. A classic example of this that we ran into a couple of years ago was a production problem where a WebSocket connection would frequently disconnect. After extensive debugging, Steve discovered that the issue was caused by the CDN provider (CloudFlare) timing out the WebSocket after two minutes—something that could only be identified by debugging the entire system, not just the application code. System-level debugging requires a broad understanding of how different components of the infrastructure interact with each other. It also involves using tools that can monitor and analyze the behavior of the system as a whole, such as network analyzers, logging frameworks, and performance monitoring tools. Embracing Complexity Full stack debugging is inherently complex, as it requires developers to navigate multiple layers of an application, often dealing with unfamiliar technologies and tools. However, this complexity also presents an opportunity for growth. By embracing the challenges of full stack debugging, developers can expand their knowledge and become more versatile in their roles. One of the key strengths of full stack development is the ability to collaborate with domain experts. When debugging an issue that spans multiple layers, it is important to leverage the expertise of colleagues who specialize in specific areas. This collaborative approach not only helps to resolve issues more efficiently but also fosters a culture of knowledge sharing and continuous learning within the team. As tools continue to evolve, so too do the tools and techniques available for debugging. Developers should strive to stay up-to-date with the latest advancements in debugging tools and best practices. Whether it’s learning to use new features in browser developer tools or mastering system-level debugging techniques, continuous learning is essential for success in full stack development. Conclusion Full stack debugging is a critical skill for modern developers, we mistakenly think it requires deep understanding of both the application and its surrounding environment. I disagree... By mastering the tools and techniques discussed in this post/upcoming posts, developers can more effectively diagnose and resolve issues that span multiple layers of the stack. Whether you’re dealing with obfuscated frontend code, misconfigured backend services, or system-level issues, the key to successful debugging lies in a methodical, collaborative approach. You don't need to understand every part of the system, just the ability to eliminate the impossible. Full stack development is often likened to an intricate balancing act, where developers are expected to juggle multiple responsibilities across the frontend, backend, database, and beyond. As the definition of full stack development continues to evolve, so too does the approach to debugging. Full stack debugging is an essential skill for developers, as it involves tracking issues through multiple layers of an application, often navigating domains where one’s knowledge may only be cursory. In this blog post I aim to explore the nuances of full stack debugging, offering practical tips and insights for developers navigating the complex web of modern software development. Notice that this is an introductory post focusing mostly on the front end debugging aspects, in the following posts I will dig deeper into the less familiar capabilities in front end debugging. https://www.youtube.com/watch?v=mM8p2VrrEaE&embedable=true https://www.youtube.com/watch?v=mM8p2VrrEaE&embedable=true As a side note, if you like the content of this and the other posts in this series check out my Debugging book that covers t his subject. If you have friends that are learning to code I'd appreciate a reference to my Java Basics book. If you want to get back to Java after a while check out my Java 8 to 21 book . Debugging book t Java Basics book. Java 8 to 21 book . Full Stack Development, A Shifting Definition The definition of full stack development is as fluid as the technology stacks themselves. Traditionally, full stack developers were defined as those who could work on both the frontend and backend of an application. However, as the industry evolves, this definition has expanded to include aspects of operations (OPS) and configuration. The modern full stack developer is expected to submit pull requests that cover all parts required to implement a feature—backend, database, frontend, and configuration. While this does not make them an expert in all these areas, it does require them to navigate across domains, often relying on domain experts for guidance. I've heard it said that full stack developers are: Jack of all trades, master of none. Jack of all trades, master of none. However, the full quote probably better represents the reality: Jack of all trades, master of none, but better than a master of one. Jack of all trades, master of none, but better than a master of one . but better than a master of one The Full Stack Debugging Approach Just as full stack development involves working across various domains, full stack debugging requires a similar approach. A symptom of a bug may manifest in the frontend, but its root cause could lie deep within the backend or database layers. Full stack debugging is about tracing these issues through the layers and isolating them as quickly as possible. This is no easy task, especially when dealing with complex systems where multiple layers interact in unexpected ways. The key to successful full stack debugging lies in understanding how to track an issue through each layer of the stack and identifying common pitfalls that developers may encounter. Frontend Debugging: Tools and Techniques It isn't "Just Console.log" Frontend developers are often stereotyped as relying solely on Console.log for debugging. While this method is simple and effective for basic debugging tasks, it falls short when dealing with the complex challenges of modern web development. The complexity of frontend code has increased significantly, making advanced debugging tools not just useful, but necessary. Yet, despite the availability of powerful debugging tools, many developers continue to shy away from them, clinging to old habits. Console.log The Power of Developer Tools Modern web browsers come equipped with robust developer tools that offer a wide range of capabilities for debugging frontend issues. These tools, available in browsers like Chrome and Firefox, allow developers to inspect elements, view and edit HTML and CSS, monitor network activity, and much more. One of the most powerful, yet underutilized, features of these tools is the JavaScript debugger. The debugger allows developers to set breakpoints, step through code, and inspect the state of variables at different points in the execution. However, the complexity of frontend code, particularly when it has been obfuscated for performance reasons, can make debugging a challenging task. We can launch the browser tools on Firefox using this menu: On Chrome we can use this option: I prefer working with Firefox, I find their developer tools more convenient but both browsers have similar capabilities. Both have fantastic debuggers (as you can see with the Firefox debugger below), unfortunately many developers limit themselves to console printing instead of exploring this powerful tool. Tackling Code Obfuscation Code obfuscation is a common practice in frontend development, employed to protect proprietary code and reduce file sizes for better performance. However, obfuscation also makes the code difficult to read and debug. Fortunately, both Chrome and Firefox developer tools provide a feature to de-obfuscate code, making it more readable and easier to debug. By clicking the curly brackets button in the toolbar, developers can transform a single line of obfuscated code into a well-formed, debuggable file. Another important tool in the fight against obfuscation is the source map. Source maps are files that map obfuscated code back to its original source code, including comments. When generated and properly configured, source maps allow developers to debug the original code instead of the obfuscated version. In Chrome, this feature can be enabled by ensuring that "Enable JavaScript source maps" is checked in the developer tools settings. You can use code like this in the JavaScript file to point at the sourcemap file: //@sourceMappingURL=myfile.js.map //@sourceMappingURL=myfile.js.map For this to work in Chrome we need to ensure that "Enable JavaScript source maps" is checked in the settings. Last I checked it was on by default but it doesn't hurt to verify: Debugging Across Layers Isolating Issues Across the Stack In full stack development, issues often manifest in one layer but originate in another. For example, a frontend error might be caused by a misconfigured backend service or a database query that returns unexpected results. Isolating the root cause of these issues requires a methodical approach, starting from the symptom and working backward through the layers. A common strategy is to reproduce the issue in a controlled environment, such as a local development setup, where each layer of the stack can be tested individually. This helps to narrow down the potential sources of the problem. Once the issue has been isolated to a specific layer, developers can use the appropriate tools and techniques to diagnose and resolve it. The Importance of System-Level Debugging Full stack debugging is not limited to the application code. Often, issues arise from the surrounding environment, such as network configurations, third-party services, or hardware limitations. A classic example of this that we ran into a couple of years ago was a production problem where a WebSocket connection would frequently disconnect. After extensive debugging, Steve discovered that the issue was caused by the CDN provider (CloudFlare) timing out the WebSocket after two minutes—something that could only be identified by debugging the entire system, not just the application code. Steve System-level debugging requires a broad understanding of how different components of the infrastructure interact with each other. It also involves using tools that can monitor and analyze the behavior of the system as a whole, such as network analyzers, logging frameworks, and performance monitoring tools. Embracing Complexity Full stack debugging is inherently complex, as it requires developers to navigate multiple layers of an application, often dealing with unfamiliar technologies and tools. However, this complexity also presents an opportunity for growth. By embracing the challenges of full stack debugging, developers can expand their knowledge and become more versatile in their roles. One of the key strengths of full stack development is the ability to collaborate with domain experts. When debugging an issue that spans multiple layers, it is important to leverage the expertise of colleagues who specialize in specific areas. This collaborative approach not only helps to resolve issues more efficiently but also fosters a culture of knowledge sharing and continuous learning within the team. As tools continue to evolve, so too do the tools and techniques available for debugging. Developers should strive to stay up-to-date with the latest advancements in debugging tools and best practices. Whether it’s learning to use new features in browser developer tools or mastering system-level debugging techniques, continuous learning is essential for success in full stack development. Conclusion Full stack debugging is a critical skill for modern developers, we mistakenly think it requires deep understanding of both the application and its surrounding environment. I disagree... By mastering the tools and techniques discussed in this post/upcoming posts, developers can more effectively diagnose and resolve issues that span multiple layers of the stack. Whether you’re dealing with obfuscated frontend code, misconfigured backend services, or system-level issues, the key to successful debugging lies in a methodical, collaborative approach. You don't need to understand every part of the system, just the ability to eliminate the impossible.

Understanding the Art of Full Stack Debugging

If the purpose is to understand how the the brain works, where in the brain is physicalism? Or, where in the brain is dualism? What part of the brain is materialism? How has the philosophy of mind defined the human mind, exactly for components within the cranium? There would have been eras that physicalism, dualism, materialism, panpsychism and several other philosophical takes may have held court with descriptions of how the mind or body worked, but with advances in neuroscience, there is little to no fit for their expressions. There are currently difficult problems of the mind like substance abuse, gambling addiction, mental disorders, and more. These are not problems that need more labels, but problems that, at minimum, any theory should state how the mind is operational while they are in effect and what could be done against their tides. Even within neuroscience, how the brain works is simply not neurons, neural circuits, or a population of neuronsbecause if a cluster of neurons mechanizes a function, what exactly is the cluster doing that another cluster is not? If it is stated that it is yet to be understood, then what theory of neural circuit has expressed why a [neurons] group specializes in a function? Neurons are not like changing. Neurons are close to solid [physical] forms, so it is unlikely that they are getting shaped in one direction that would indicate why they interpret a smell differently from the next, or a smell from a sound. Simply, neurons are not having direct anatomic changes to ensure a function, in contrast to another function. Even with synapses, when strong or weak, what must be definitive in every synapse? Assuming the philosophy of mind had looked closely at clusters of neurons in the last century to base many of its takes, maybe it would have been ahead of science. So far, philosophy of mind is no longer ahead of neuroscience and may not even be much linked anymore, since the philosophy chooses what it wants but the science is vacant for an advance within the cranium. The closest options to what the mind is and how the mind works is theorized to be the electrical and chemical signals of nerve cells, in sets, in clusters of neurons. It is the configuration of the signals, their interactions, and features that could be zeroed in on for how the human mind works. There is no function of neurons—for the mind—that signals are not involved in. There is no synapse—chemical or electrical—that is absent of signals. Genes are not the human mind. The environment is not the human mind. Neurons are not the human mind. Elementary particles of physics are not the human mind. Neuroglia are not the human mind as well. To answer questions about the human mind is to seek out what the mind might be in the cranium, not stray juxtapositions that, no matter how cutely described, cannot even answer for mental disorders, in the same mind for which several consciousness or philosophical stretches should define. To properly evaluate any consciousness theory or philosophical theory of mind, questions—on what the mind is [in the cranium, not the mind of the universe], how it works distinctively and how it may explain or suggest solutions to mind problems—should be sought, not generalized neuroimaging, adversarial collaboration or vague correlates. It is like trying to understand how human memory works, with mentions of long-term, short-term and others, without naming relays across memory destinations or if the configuration of any memory is different from an emotion or a feeling, or the exact forms for which memories are associated. There is a new book featured on The Transmitter, How did consciousness evolve? An excerpt from ‘A History of Bodies, Brains, and Minds: The Evolution of Life and Consciousness’, stating that, "However, life is a scientifically observable phenomenon, while our subjective experiences are not accessible to third parties. Furthermore, for conscious subjects, their own life is an experiential phenomenon as well. One alternative to get away from the mind-body conundrum has been pan-psychism, which is an extension of the identity hypothesis, proposing that some degree of consciousness is a feature of the universe like energy or gravity are. Some other researchers, particularly physicists, have moved much farther, proposing that the source of consciousness relies on quantum mechanics. In this view, quantal superpositions of states in elementary particles would collapse wave functions into (proto-) moments of experience composed of basic qualia, the fundamental ‘particles’ of consciousness. However, despite the apparent relation between consciousness and complexity, how material mechanisms become transformed into a first-person qualitative experience poses a major problem for neuroscientific research, which is conceived to deal with second-person observable phenomena. Because the unobservable nature of subjective states by second parties severely limits their scientific study, some have decided to downplay them as an irrelevant illusion generated by our complex brain networks. Whether consciousness is or is not relevant for our decisions and behavior is a debatable issue, but the illusion argument does not really explain to me how subjectivity is in fact produced." There is a recent paper in Nature, Neural populations in the language network differ in the size of their temporal receptive windows, stating that, "Despite long knowing what brain areas support language comprehension, our knowledge of the neural computations that these frontal and temporal regions implement remains limited. One important unresolved question concerns functional differences among the neural populations that comprise the language network. Neural populations exhibiting these profiles are interleaved across the language network, which suggests that all language regions have direct access to distinct, multiscale representations of linguistic input—a property that may be critical for the efficiency and robustness of language processing." If the purpose is to understand how the the brain works, where in the brain is physicalism? Or, where in the brain is dualism? What part of the brain is materialism? How has the philosophy of mind defined the human mind, exactly for components within the cranium? There would have been eras that physicalism, dualism, materialism, panpsychism and several other philosophical takes may have held court with descriptions of how the mind or body worked, but with advances in neuroscience, there is little to no fit for their expressions. There are currently difficult problems of the mind like substance abuse, gambling addiction, mental disorders, and more. These are not problems that need more labels, but problems that, at minimum, any theory should state how the mind is operational while they are in effect and what could be done against their tides. Even within neuroscience, how the brain works is simply not neurons, neural circuits, or a population of neurons because if a cluster of neurons mechanizes a function, what exactly is the cluster doing that another cluster is not? how the brain works is simply not neurons, neural circuits, or a population of neurons If it is stated that it is yet to be understood, then what theory of neural circuit has expressed why a [neurons] group specializes in a function? Neurons are not like changing. Neurons are close to solid [physical] forms, so it is unlikely that they are getting shaped in one direction that would indicate why they interpret a smell differently from the next, or a smell from a sound. Simply, neurons are not having direct anatomic changes to ensure a function, in contrast to another function. Even with synapses, when strong or weak, what must be definitive in every synapse? Assuming the philosophy of mind had looked closely at clusters of neurons in the last century to base many of its takes, maybe it would have been ahead of science. So far, philosophy of mind is no longer ahead of neuroscience and may not even be much linked anymore, since the philosophy chooses what it wants but the science is vacant for an advance within the cranium. The closest options to what the mind is and how the mind works is theorized to be the electrical and chemical signals of nerve cells, in sets, in clusters of neurons. It is the configuration of the signals, their interactions, and features that could be zeroed in on for how the human mind works. There is no function of neurons—for the mind—that signals are not involved in. There is no synapse—chemical or electrical—that is absent of signals. Genes are not the human mind . The environment is not the human mind. Neurons are not the human mind. Elementary particles of physics are not the human mind. Neuroglia are not the human mind as well. Genes are not the human mind To answer questions about the human mind is to seek out what the mind might be in the cranium, not stray juxtapositions that, no matter how cutely described, cannot even answer for mental disorders, in the same mind for which several consciousness or philosophical stretches should define. To properly evaluate any consciousness theory or philosophical theory of mind, questions—on what the mind is [in the cranium, not the mind of the universe], how it works distinctively and how it may explain or suggest solutions to mind problems—should be sought, not generalized neuroimaging, adversarial collaboration or vague correlates. It is like trying to understand how human memory works, with mentions of long-term, short-term and others, without naming relays across memory destinations or if the configuration of any memory is different from an emotion or a feeling, or the exact forms for which memories are associated. There is a new book featured on The Transmitter , How did consciousness evolve? An excerpt from ‘A History of Bodies, Brains, and Minds: The Evolution of Life and Consciousness’ , stating that, "However, life is a scientifically observable phenomenon, while our subjective experiences are not accessible to third parties. Furthermore, for conscious subjects, their own life is an experiential phenomenon as well. One alternative to get away from the mind-body conundrum has been pan-psychism, which is an extension of the identity hypothesis, proposing that some degree of consciousness is a feature of the universe like energy or gravity are. Some other researchers, particularly physicists, have moved much farther, proposing that the source of consciousness relies on quantum mechanics. In this view, quantal superpositions of states in elementary particles would collapse wave functions into (proto-) moments of experience composed of basic qualia, the fundamental ‘particles’ of consciousness. However, despite the apparent relation between consciousness and complexity, how material mechanisms become transformed into a first-person qualitative experience poses a major problem for neuroscientific research, which is conceived to deal with second-person observable phenomena. Because the unobservable nature of subjective states by second parties severely limits their scientific study, some have decided to downplay them as an irrelevant illusion generated by our complex brain networks. Whether consciousness is or is not relevant for our decisions and behavior is a debatable issue, but the illusion argument does not really explain to me how subjectivity is in fact produced." The Transmitter How did consciousness evolve? An excerpt from ‘A History of Bodies, Brains, and Minds: The Evolution of Life and Consciousness’ There is a recent paper in Nature , Neural populations in the language network differ in the size of their temporal receptive windows , stating that, "Despite long knowing what brain areas support language comprehension, our knowledge of the neural computations that these frontal and temporal regions implement remains limited. One important unresolved question concerns functional differences among the neural populations that comprise the language network. Neural populations exhibiting these profiles are interleaved across the language network, which suggests that all language regions have direct access to distinct, multiscale representations of linguistic input—a property that may be critical for the efficiency and robustness of language processing." Nature Neural populations in the language network differ in the size of their temporal receptive windows

Consciousness: Why Philosophy of Mind May No Longer Be Relevant to Neuroscience

Escaping Characters To display a literal character that would otherwise be used to format text in a Markdown document, add a backslash (\) in front of the character. \* Without the backslash, this would be a bullet in an unordered list. The rendered output looks like this: * Without the backslash, this would be a bullet in an unordered list. Characters You Can Escape You can use a backslash to escape the following characters. Character

Name





backslash



`

backtick (see also escaping backticks in code)



*

asterisk



_

underscore



{ }

curly braces



[ ]

brackets



< >

angle brackets



( )

parentheses



#

pound sign



+

plus sign



-

minus sign (hyphen)



.

dot



!

exclamation mark



|

pipe (see also escaping pipe in tables) This guide is a Matt Cone project available on Markdown Guide under the CC BY-SA 4.0 license. Escaping Characters To display a literal character that would otherwise be used to format text in a Markdown document, add a backslash ( \ ) in front of the character. \ \* Without the backslash, this would be a bullet in an unordered list. \* Without the backslash, this would be a bullet in an unordered list. The rendered output looks like this: * Without the backslash, this would be a bullet in an unordered list. Characters You Can Escape You can use a backslash to escape the following characters. Character

Name





backslash



`

backtick (see also escaping backticks in code)



*

asterisk



_

underscore



{ }

curly braces



[ ]

brackets



< >

angle brackets



( )

parentheses



#

pound sign



+

plus sign



-

minus sign (hyphen)



.

dot



!

exclamation mark



|

pipe (see also escaping pipe in tables) Character

Name backslash `

backtick (see also escaping backticks in code) *

asterisk _

underscore { }

curly braces [ ]

brackets < >

angle brackets ( )

parentheses #

pound sign +

plus sign -

minus sign (hyphen) .

dot !

exclamation mark |

pipe (see also escaping pipe in tables) Character Name Character Character Name Name backslash backslash backslash ` backtick (see also escaping backticks in code) ` ` backtick (see also escaping backticks in code) backtick (see also escaping backticks in code ) escaping backticks in code * asterisk * * asterisk asterisk _ underscore _ _ underscore underscore { } curly braces { } { } curly braces curly braces [ ] brackets [ ] [ ] brackets brackets < > angle brackets < > < > angle brackets angle brackets ( ) parentheses ( ) ( ) parentheses parentheses # pound sign # # pound sign pound sign + plus sign + + plus sign plus sign - minus sign (hyphen) - - minus sign (hyphen) minus sign (hyphen) . dot . . dot dot ! exclamation mark ! ! exclamation mark exclamation mark | pipe (see also escaping pipe in tables) | | pipe (see also escaping pipe in tables) pipe (see also escaping pipe in tables ) escaping pipe in tables This guide is a Matt Cone project available on Markdown Guide under the CC BY-SA 4.0 license. This guide is a Matt Cone project available on Markdown Guide under the CC BY-SA 4.0 license. Matt Cone Markdown Guide

The Dead Simple Markdown Guide to Escaping Characters

Mastering JavaScript Objects: A Comprehensive Guide

Author:
(1) David S. Hardin, Cedar Rapids, IA USA david.s.hardin@gmail.com. Table of Links Abstract and Introduction
Dancing Links
The Rust Programming Language
RAC: Hardware/Software Co-Assurance at Scale
Rust and RAR
Dancing Links in Rust
Related Work
Conclusion, Acknowledgments, and References 6 Dancing Links in Rust In this section, we describe an array-based circular doubly-linked list (CDLL) employing Knuth’s “Dancing Links” optimization, realized using our RAR Rust subset. The CDLL data structure implementation constitutes over 700 lines of Rust code, which becomes 890 lines of code when translated to ACL2. 6.1 Definitions First, we present the basic RAR declaration for the CDLL. Rust data structure declarations are similar to those in C, but struct elements are declared by specifying the element name, followed by the : separator, then the element type. Also note that Rust pragmas may be given using the derive attribute. In the declaration above, the array nodeArr holds the list element nodes. Each element has next and prev indices. Note that indices in Rust are normally declared to be of the usize type. Note also that by using array indices instead of references, we get around Rust ownership model issues with circular data structures. The alloc field of the CDLLNode structure is declared to be a two bit unsigned field, but its only allowed values are two non-zero values: 2 (not currently allocated), and 3 (allocated). The reason for this has to do with the details of ACL2 untyped record reasoning, which will be discussed in Section 6.2. The Dancing Links operators cdll_remove and cdll_restore are presented in Figures 4 and 5, respectively. Rust functions begin with the fn keyword, followed by the function name, a parenthesized list of parameters, the -> (returns) symbol, the return type name, followed by the function body (delimited by a curly brace pair). A function parameter list element consists of the parameter name, the : symbol, then the parameter type. Additional parameter modifiers, for example mut, may be present to indicate that the parameter is changed in the function body. Within the function body, the syntax is similar to other C-like languages, but local variable declarations begin with let, and use the variable name, :, variable type declaration syntax. A local variable declaration may also require the mut modifier if that local variable is updated after its initialization. 6.2 Translation to ACL2 We use Plexi to transpile the RAR source to RAC (not shown), then use the RAC translator to convert the resulting RAC source to ACL2. The translation of cdll_restore() appears in Fig. 6. The first thing to note about Fig. 6 is that, even though we are two translation steps away from the original RAR source, the translated function is nonetheless quite readable, which is a rare thing for machine-generated code. Another notable observation is that struct and array ‘get’ and ‘set’ operations become untyped record operators, AG and AS, respectively — these are slight RAC-specific customizations of the usual ACL2 untyped record operators. Further, IF1 is a RAC-specific macro, and LOG>, LOG=, LOG<, and LOGIOR1 are all RTL functions. Thus, much of the proof effort involved with RAR code is reasoning about untyped records and RTL — although not a lot of RTL-specific knowledge is needed, at least in our experience. One aspect of untyped records that can be tricky is that record elements that take on the default value are not explicitly stored in the association list for the record. For RAC untyped records, that default value is zero. Thus, it is easy for a given record to attain a nil value. When reasoning about arrays of such records, it is often desirable to be able to state that the array size remains constant. Thus, for example, for the CDLL array nodeArr of Section 6.1, we ensure that all CDLLNode elements of that array are non-nil by making sure that the alloc fields of the CDLLNode elements are always non-zero (2 or 3). 6.3 Dancing Links Theorems Once we have translated the circular doubly-linked list functions into ACL2, we can begin to prove theorems about the data structure implementation. We begin by defining a “well-formedness” predicate for CDLLs. Given this definition of a good CDLL state, we can prove functional correctness theorems for Dancing Links operations, of the sort stated below. Note that this proof requires some detailed well-formedness hypotheses related to the prev and next indices for the nth element: ACL2 performs the correctness proof for this cdll_restore of cdll_remove theorem automatically. In addition to the Dancing Links operator proofs, we have proved approximately 160 theorems related to the CDLL data structure, including theorems about cdll_cns() (cons equivalent), cdll_- rst() (cdr equivalent), cdll_snc() (add to end of data structure), cdll_tsr() (delete from end of data structure), cdll_nth(), etc. All of these proofs will be made publicly available in the ACL2 workshop books repository. This paper is available on arxiv under CC 4.0 license. Author: (1) David S. Hardin, Cedar Rapids, IA USA david.s.hardin@gmail.com. Author: Author: (1) David S. Hardin, Cedar Rapids, IA USA david.s.hardin@gmail.com. Table of Links Abstract and Introduction Dancing Links The Rust Programming Language RAC: Hardware/Software Co-Assurance at Scale Rust and RAR Dancing Links in Rust Related Work Conclusion, Acknowledgments, and References Abstract and Introduction Abstract and Introduction Dancing Links Dancing Links The Rust Programming Language The Rust Programming Language RAC: Hardware/Software Co-Assurance at Scale RAC: Hardware/Software Co-Assurance at Scale Rust and RAR Rust and RAR Dancing Links in Rust Dancing Links in Rust Related Work Related Work Conclusion, Acknowledgments, and References Conclusion, Acknowledgments, and References 6 Dancing Links in Rust In this section, we describe an array-based circular doubly-linked list (CDLL) employing Knuth’s “Dancing Links” optimization, realized using our RAR Rust subset. The CDLL data structure implementation constitutes over 700 lines of Rust code, which becomes 890 lines of code when translated to ACL2. 6.1 Definitions First, we present the basic RAR declaration for the CDLL. Rust data structure declarations are similar to those in C, but struct elements are declared by specifying the element name, followed by the : separator, then the element type. Also note that Rust pragmas may be given using the derive attribute. In the declaration above, the array nodeArr holds the list element nodes. Each element has next and prev indices. Note that indices in Rust are normally declared to be of the usize type. Note also that by using array indices instead of references, we get around Rust ownership model issues with circular data structures. The alloc field of the CDLLNode structure is declared to be a two bit unsigned field, but its only allowed values are two non-zero values: 2 (not currently allocated), and 3 (allocated). The reason for this has to do with the details of ACL2 untyped record reasoning, which will be discussed in Section 6.2. The Dancing Links operators cdll_remove and cdll_restore are presented in Figures 4 and 5, respectively. Rust functions begin with the fn keyword, followed by the function name, a parenthesized list of parameters, the -> (returns) symbol, the return type name, followed by the function body (delimited by a curly brace pair). A function parameter list element consists of the parameter name, the : symbol, then the parameter type. Additional parameter modifiers, for example mut, may be present to indicate that the parameter is changed in the function body. Within the function body, the syntax is similar to other C-like languages, but local variable declarations begin with let, and use the variable name, :, variable type declaration syntax. A local variable declaration may also require the mut modifier if that local variable is updated after its initialization. 6.2 Translation to ACL2 We use Plexi to transpile the RAR source to RAC (not shown), then use the RAC translator to convert the resulting RAC source to ACL2. The translation of cdll_restore() appears in Fig. 6. The first thing to note about Fig. 6 is that, even though we are two translation steps away from the original RAR source, the translated function is nonetheless quite readable, which is a rare thing for machine-generated code. Another notable observation is that struct and array ‘get’ and ‘set’ operations become untyped record operators, AG and AS, respectively — these are slight RAC-specific customizations of the usual ACL2 untyped record operators. Further, IF1 is a RAC-specific macro, and LOG>, LOG=, LOG<, and LOGIOR1 are all RTL functions. Thus, much of the proof effort involved with RAR code is reasoning about untyped records and RTL — although not a lot of RTL-specific knowledge is needed, at least in our experience. One aspect of untyped records that can be tricky is that record elements that take on the default value are not explicitly stored in the association list for the record. For RAC untyped records, that default value is zero. Thus, it is easy for a given record to attain a nil value. When reasoning about arrays of such records, it is often desirable to be able to state that the array size remains constant. Thus, for example, for the CDLL array nodeArr of Section 6.1, we ensure that all CDLLNode elements of that array are non-nil by making sure that the alloc fields of the CDLLNode elements are always non-zero (2 or 3). 6.3 Dancing Links Theorems Once we have translated the circular doubly-linked list functions into ACL2, we can begin to prove theorems about the data structure implementation. We begin by defining a “well-formedness” predicate for CDLLs. Given this definition of a good CDLL state, we can prove functional correctness theorems for Dancing Links operations, of the sort stated below. Note that this proof requires some detailed well-formedness hypotheses related to the prev and next indices for the nth element: ACL2 performs the correctness proof for this cdll_restore of cdll_remove theorem automatically. In addition to the Dancing Links operator proofs, we have proved approximately 160 theorems related to the CDLL data structure, including theorems about cdll_cns() (cons equivalent), cdll_- rst() (cdr equivalent), cdll_snc() (add to end of data structure), cdll_tsr() (delete from end of data structure), cdll_nth(), etc. All of these proofs will be made publicly available in the ACL2 workshop books repository. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Verification of a Rust Implementation of Knuth’s Dancing Links Using ACL2: Dancing Links in Rust

Unitarity Bound on Dark Matter in Low-temperature Reheating Scenarios: Acknowledgments and Reference

নিম্ন-তাপমাত্রা পুনঃউষ্ণকরণের পরিস্থিতিতে ডার্ক ম্যাটারে ঐক্যবদ্ধতা: স্বীকৃতি এবং রেফারেন্স

Unitaritätsgrenze für Dunkle Materie in Niedertemperatur-Wiedererwärmungsszenarien: Danksagungen und Referenz

Unitaridad unida a la materia oscura en escenarios de recalentamiento a baja temperatura: reconocimientos y referencias

Unitarité liée à la matière noire dans les scénarios de réchauffage à basse température : remerciements et référence

निम्न-तापमान पुनःतापन परिदृश्यों में डार्क मैटर पर यूनिटैरिटी बाउंड: आभार और संदर्भ

低温再加熱シナリオにおける暗黒物質のユニタリー性限界: 謝辞と参考文献

저온 재가열 시나리오에서 암흑물질에 결합된 단일성: 승인 및 참고자료

Unitariedade vinculada à matéria escura em cenários de reaquecimento de baixa temperatura: reconhecimentos e referências

Унитарность, связанная с темной материей в сценариях низкотемпературного разогрева: благодарности и ссылки

Düşük Sıcaklıkta Yeniden Isıtma Senaryolarında Karanlık Maddeye Bağlı Üniterlik: Teşekkür ve Referans

Tính thống nhất bị ràng buộc đối với Vật chất tối trong các kịch bản hâm nóng ở nhiệt độ thấp: Lời cảm ơn và tài liệu tham khảo

低温再加热场景中暗物质的幺正性界限：致谢和参考文献

Functions are a fundamental concept in JavaScript, allowing developers to encapsulate code for reuse, organization, and abstraction. In this guide, we’ll explore various aspects of functions in JavaScript, including their declaration, parameters, return statements, function expressions, and arrow functions. 1. Declaration of Functions In JavaScript, functions can be declared using the function keyword followed by the function name and a pair of parentheses () containing optional parameters. Here's a basic example: function greet(name) {
return Hello, ${name}!;
}

console.log(greet('sadanand gadwal')); // Output: Hello, sadanand gadwal! The greet function is declared using the function keyword. It takes a parameter name and returns a greeting message using string interpolation. Parameters
Functions can accept parameters, which are variables that hold the values passed to the function when it is called. Parameters are declared within the parentheses following the function name.
Here's an example function add(a, b) {
return a + b;
}

console.log(add(5, 3)); // Output: 8 The add function takes two parameters a and b and returns their sum.
The subtract function takes two parameters a and b and returns the result of a - b. 3. Return Statements Functions can use the return statement to send a value back to the code that called the function. If a function doesn't explicitly return a value, it implicitly returns undefined. Here's an example: function subtract(a, b) {
 return a - b;
}

console.log(subtract(10, 4)); // Output: 6 Both add and subtract functions use the return statement to return the result of the arithmetic operation. 4. Function Expressions Function expressions define functions as part of an expression rather than as a declaration. They can be named or anonymous and are often used to assign functions to variables. Here’s an example of a named function expression: const multiply = function multiply(a, b) {
    return a * b;
};

console.log(multiply(7, 8)); // Output: 56 And here’s an example of an anonymous function expression: const divide = function(a, b) {
    return a / b;
};

console.log(divide(100, 5)); // Output: 20 The multiply function is defined using a named function expression. The function is assigned to the variable multiply.
The divide function is defined using an anonymous function expression. The function is assigned to the variable divide. 5. Arrow Functions Arrow functions are a more concise way to write functions in JavaScript, introduced in ES6. They have a more compact syntax and automatically bind this to the surrounding code's context. Here's an example: const square = (x) => {
    return x * x;
};

console.log(square(4)); // Output: 16 For simple functions that have only one expression in the body, the curly braces and return keyword can be omitted: const cube = (x) => x * x * x;

console.log(cube(3)); // Output: 27 The square function is defined using an arrow function. It takes a parameter x and returns the square of x.
The cube function is also defined using an arrow function but with a more concise syntax since it has only one expression in its body. 6. Example: Using Functions function calculate(operation, a, b) {
    switch (operation) {
        case 'add':
            return add(a, b);
        case 'subtract':
            return subtract(a, b);
        case 'multiply':
            return multiply(a, b);
        case 'divide':
            return divide(a, b);
        default:
            return 'Invalid operation';
    }
}

console.log(calculate('add', 5, 3)); // Output: 8
console.log(calculate('multiply', 4, 6)); // Output: 24
console.log(calculate('divide', 10, 2)); // Output: 5
console.log(calculate('power', 2, 3)); // Output: Invalid operation The calculate function takes three parameters: operation, a, and b. It uses a switch statement to determine which operation to perform (add, subtract, multiply, divide) and calls the corresponding function with the given arguments.
The switch statement also handles the case when an invalid operation is provided, returning an error message. Conclusion Functions are a powerful feature in JavaScript, allowing developers to write modular and reusable code. Understanding the different ways to declare and use functions is essential for any JavaScript developer. Bonus: Complete code: // Declaration of Functions
function greet(name) {
    return `Hello, ${name}!`;
}

// Parameters
function add(a, b) {
    return a + b;
}

// Return Statements
function subtract(a, b) {
    return a - b;
}

// Function Expressions
const multiply = function multiply(a, b) {
    return a * b;
};

const divide = function(a, b) {
    return a / b;
};

// Arrow Functions
const square = (x) => {
    return x * x;
};

const cube = (x) => x * x * x;

// Example: Using Functions
function calculate(operation, a, b) {
    switch (operation) {
        case 'add':
            return add(a, b);
        case 'subtract':
            return subtract(a, b);
        case 'multiply':
            return multiply(a, b);
        case 'divide':
            return divide(a, b);
        default:
            return 'Invalid operation';
    }
}

console.log(greet('sadanand gadwal')); // Output: Hello, sadanand gadwal!
console.log(add(5, 3)); // Output: 8
console.log(subtract(10, 4)); // Output: 6
console.log(multiply(7, 8)); // Output: 56
console.log(divide(100, 5)); // Output: 20
console.log(square(4)); // Output: 16
console.log(cube(3)); // Output: 27
console.log(calculate('add', 5, 3)); // Output: 8
console.log(calculate('multiply', 4, 6)); // Output: 24
console.log(calculate('divide', 10, 2)); // Output: 5
console.log(calculate('power', 2, 3)); // Output: Invalid operation 🌟 Stay Connected! 🌟 Hey there, awesome reader! 👋 Want to stay updated with my latest insights? Follow me on social media! 🐦 📸 📘 💻 🌐 Functions are a fundamental concept in JavaScript, allowing developers to encapsulate code for reuse, organization, and abstraction. In this guide, we’ll explore various aspects of functions in JavaScript, including their declaration, parameters, return statements, function expressions, and arrow functions. 1. Declaration of Functions Declaration of Functions In JavaScript, functions can be declared using the function keyword followed by the function name and a pair of parentheses () containing optional parameters. function () Here's a basic example: function greet(name) {
return Hello, ${name}!;
}

console.log(greet('sadanand gadwal')); // Output: Hello, sadanand gadwal! function greet(name) {
return Hello, ${name}!;
}

console.log(greet('sadanand gadwal')); // Output: Hello, sadanand gadwal! The greet function is declared using the function keyword. It takes a parameter name and returns a greeting message using string interpolation. The greet function is declared using the function keyword. It takes a parameter name and returns a greeting message using string interpolation. Parameters
Functions can accept parameters, which are variables that hold the values passed to the function when it is called. Parameters are declared within the parentheses following the function name.
Here's an example Parameters Functions can accept parameters, which are variables that hold the values passed to the function when it is called. Parameters are declared within the parentheses following the function name. Here's an example Parameters Parameters Functions can accept parameters, which are variables that hold the values passed to the function when it is called. Parameters are declared within the parentheses following the function name. Here's an example function add(a, b) {
return a + b;
}

console.log(add(5, 3)); // Output: 8 function add(a, b) {
return a + b;
}

console.log(add(5, 3)); // Output: 8 The add function takes two parameters a and b and returns their sum. The subtract function takes two parameters a and b and returns the result of a - b. The add function takes two parameters a and b and returns their sum. add a b The subtract function takes two parameters a and b and returns the result of a - b . subtract a b a - b 3. Return Statements Return Statements Functions can use the return statement to send a value back to the code that called the function. If a function doesn't explicitly return a value, it implicitly returns undefined . return undefined Here's an example: function subtract(a, b) {
 return a - b;
}

console.log(subtract(10, 4)); // Output: 6 function subtract(a, b) {
 return a - b;
}

console.log(subtract(10, 4)); // Output: 6 Both add and subtract functions use the return statement to return the result of the arithmetic operation. Both add and subtract functions use the return statement to return the result of the arithmetic operation. add subtract return 4. Function Expressions Function Expressions Function expressions define functions as part of an expression rather than as a declaration. They can be named or anonymous and are often used to assign functions to variables. Here’s an example of a named function expression: const multiply = function multiply(a, b) {
    return a * b;
};

console.log(multiply(7, 8)); // Output: 56 const multiply = function multiply(a, b) {
    return a * b;
};

console.log(multiply(7, 8)); // Output: 56 And here’s an example of an anonymous function expression: anonymous function expression: const divide = function(a, b) {
    return a / b;
};

console.log(divide(100, 5)); // Output: 20 const divide = function(a, b) {
    return a / b;
};

console.log(divide(100, 5)); // Output: 20 The multiply function is defined using a named function expression. The function is assigned to the variable multiply. The divide function is defined using an anonymous function expression. The function is assigned to the variable divide. The multiply function is defined using a named function expression. The function is assigned to the variable multiply . multiply multiply The divide function is defined using an anonymous function expression. The function is assigned to the variable divide . divide divide 5. Arrow Functions Arrow Functions Arrow functions are a more concise way to write functions in JavaScript, introduced in ES6. They have a more compact syntax and automatically bind this to the surrounding code's context. Here's an example: this const square = (x) => {
    return x * x;
};

console.log(square(4)); // Output: 16 const square = (x) => {
    return x * x;
};

console.log(square(4)); // Output: 16 For simple functions that have only one expression in the body, the curly braces and return keyword can be omitted: one expression return const cube = (x) => x * x * x;

console.log(cube(3)); // Output: 27 const cube = (x) => x * x * x;

console.log(cube(3)); // Output: 27 The square function is defined using an arrow function. It takes a parameter x and returns the square of x. The cube function is also defined using an arrow function but with a more concise syntax since it has only one expression in its body. The square function is defined using an arrow function. It takes a parameter x and returns the square of x . square x x The cube function is also defined using an arrow function but with a more concise syntax since it has only one expression in its body. cube 6. Example: Using Functions 6. Example: Using Functions function calculate(operation, a, b) {
    switch (operation) {
        case 'add':
            return add(a, b);
        case 'subtract':
            return subtract(a, b);
        case 'multiply':
            return multiply(a, b);
        case 'divide':
            return divide(a, b);
        default:
            return 'Invalid operation';
    }
}

console.log(calculate('add', 5, 3)); // Output: 8
console.log(calculate('multiply', 4, 6)); // Output: 24
console.log(calculate('divide', 10, 2)); // Output: 5
console.log(calculate('power', 2, 3)); // Output: Invalid operation function calculate(operation, a, b) {
    switch (operation) {
        case 'add':
            return add(a, b);
        case 'subtract':
            return subtract(a, b);
        case 'multiply':
            return multiply(a, b);
        case 'divide':
            return divide(a, b);
        default:
            return 'Invalid operation';
    }
}

console.log(calculate('add', 5, 3)); // Output: 8
console.log(calculate('multiply', 4, 6)); // Output: 24
console.log(calculate('divide', 10, 2)); // Output: 5
console.log(calculate('power', 2, 3)); // Output: Invalid operation The calculate function takes three parameters: operation, a, and b. It uses a switch statement to determine which operation to perform (add, subtract, multiply, divide) and calls the corresponding function with the given arguments. The switch statement also handles the case when an invalid operation is provided, returning an error message. The calculate function takes three parameters: operation , a , and b . It uses a switch statement to determine which operation to perform ( add , subtract , multiply , divide ) and calls the corresponding function with the given arguments. calculate operation a b switch add subtract multiply divide The switch statement also handles the case when an invalid operation is provided, returning an error message. switch Conclusion Conclusion Functions are a powerful feature in JavaScript, allowing developers to write modular and reusable code. Understanding the different ways to declare and use functions is essential for any JavaScript developer. Bonus: Complete code: Bonus: Complete code: // Declaration of Functions
function greet(name) {
    return `Hello, ${name}!`;
}

// Parameters
function add(a, b) {
    return a + b;
}

// Return Statements
function subtract(a, b) {
    return a - b;
}

// Function Expressions
const multiply = function multiply(a, b) {
    return a * b;
};

const divide = function(a, b) {
    return a / b;
};

// Arrow Functions
const square = (x) => {
    return x * x;
};

const cube = (x) => x * x * x;

// Example: Using Functions
function calculate(operation, a, b) {
    switch (operation) {
        case 'add':
            return add(a, b);
        case 'subtract':
            return subtract(a, b);
        case 'multiply':
            return multiply(a, b);
        case 'divide':
            return divide(a, b);
        default:
            return 'Invalid operation';
    }
}

console.log(greet('sadanand gadwal')); // Output: Hello, sadanand gadwal!
console.log(add(5, 3)); // Output: 8
console.log(subtract(10, 4)); // Output: 6
console.log(multiply(7, 8)); // Output: 56
console.log(divide(100, 5)); // Output: 20
console.log(square(4)); // Output: 16
console.log(cube(3)); // Output: 27
console.log(calculate('add', 5, 3)); // Output: 8
console.log(calculate('multiply', 4, 6)); // Output: 24
console.log(calculate('divide', 10, 2)); // Output: 5
console.log(calculate('power', 2, 3)); // Output: Invalid operation // Declaration of Functions
function greet(name) {
    return `Hello, ${name}!`;
}

// Parameters
function add(a, b) {
    return a + b;
}

// Return Statements
function subtract(a, b) {
    return a - b;
}

// Function Expressions
const multiply = function multiply(a, b) {
    return a * b;
};

const divide = function(a, b) {
    return a / b;
};

// Arrow Functions
const square = (x) => {
    return x * x;
};

const cube = (x) => x * x * x;

// Example: Using Functions
function calculate(operation, a, b) {
    switch (operation) {
        case 'add':
            return add(a, b);
        case 'subtract':
            return subtract(a, b);
        case 'multiply':
            return multiply(a, b);
        case 'divide':
            return divide(a, b);
        default:
            return 'Invalid operation';
    }
}

console.log(greet('sadanand gadwal')); // Output: Hello, sadanand gadwal!
console.log(add(5, 3)); // Output: 8
console.log(subtract(10, 4)); // Output: 6
console.log(multiply(7, 8)); // Output: 56
console.log(divide(100, 5)); // Output: 20
console.log(square(4)); // Output: 16
console.log(cube(3)); // Output: 27
console.log(calculate('add', 5, 3)); // Output: 8
console.log(calculate('multiply', 4, 6)); // Output: 24
console.log(calculate('divide', 10, 2)); // Output: 5
console.log(calculate('power', 2, 3)); // Output: Invalid operation 🌟 Stay Connected! 🌟 🌟 Stay Connected! 🌟 Hey there, awesome reader! 👋 Want to stay updated with my latest insights? Follow me on social media! 🐦 📸 📘 💻 🌐 🐦 📸 📘 💻 🌐

Getting Started With Functions in JavaScript: Declarations, Parameters, and More

All You Need To Know About Try Catch in C#

HEPT MOVES ON

After seeing some posts on discussing collection initializers, I became curious. There was a claim that using collection expressions, instead of collection initializers, would boost performance. As a result, I set out to measure collection initializer performance in C# using BenchmarkDotNet. And yes, while these might be micro-optimizations for many people, I thought it would be cool to explore. LinkedIn Besides, maybe there’s someone out there with something like this on their hot-path that needs to squeeze a bit more out of their application 🙂 What Are Collection Initializers and Collection Expressions in C#? In one of my most recent articles, I explain . Simply put, instead of manually writing code like the following to initialize a collection: the basics of collection initializers with some simple code examples List<string> devLeaderCoolList = new List<string>();
devLeaderCoolList.Add("Hello");
devLeaderCoolList.Add(", ");
devLeaderCoolList.Add("World!"); … we can instead reduce it to something more succinct like the following: List<string> devLeaderCoolList = [ "Hello", ", ", "World!" ]; Pretty neat, right? This collection expression syntax is even more lightweight than we’ve had access to in recent times. But syntax and readability aside (Not to minimize the benefits of code readability, but I’m trying not to put you to sleep), what about the performance?! I bet you didn’t even consider, with all of the different collection initializer syntaxes available, that we’d see a change in performance! Well, Dave Callan got me thinking about that when he posted this on LinkedIn: , and that has inspired this entire article. This image was originally posted by Dave Callan on LinkedIn Let’s jump into some benchmarks! Exploring List Collection Initializer Performance in C# This section will detail the benchmarks for initializing lists in C# in various ways. I’ll provide coverage on different syntax, and even compare it to doing it manually! Surely, adding everything by hand would be slower than setting ourselves up for success by doing it all with a collection initializer — but we should cover our bases. collection initializers, the newer collection expression I will not be covering the spread operator in these benchmarks because I’d like to focus on that more for collection combination benchmarks. Admittedly, yes, it is still creating a collection… but I feel like the use case is different and I’d like to split it up. I’ll be using BenchmarkDotNet for all of these benchmarks, so if you’re not familiar with using BenchmarkDotNet you can check out the video below and see how to use it for yourself: https://www.youtube.com/watch?v=Wa3sdKGp3wE&embedable=true The List Benchmark Code With the BenchmarkDotNet NuGet installed, here’s what I am using at the entry point to kick things off (for all benchmark examples in this article): using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

using System.Reflection;

BenchmarkRunner.Run(
    Assembly.GetExecutingAssembly(),
    args: args); It’s not very exciting — but I wanted to show you there’s nothing fancy going on here. Just running all of the benchmarks we have access to. And here is the list benchmark code: [MemoryDiagnoser]
[MediumRunJob]
public class ListBenchmarks
{
    private static readonly string[] _dataAsArray = new string[]
    {
        "Apple",
        "Banana",
        "Orange",
    };

    private static IEnumerable<string> GetDataAsIterator()
    {
        yield return "Apple";
        yield return "Banana";
        yield return "Orange";
    }

    [Benchmark(Baseline = true)]
    public List<string> ClassicCollectionInitializer_NoCapacity()
    {
        return new List<string>()
        {
            "Apple",
            "Banana",
            "Orange",
        };
    }

    [Benchmark]
    public List<string> ClassicCollectionInitializer_SetCapacity()
    {
        return new List<string>(3)
        {
            "Apple",
            "Banana",
            "Orange",
        };
    }

    [Benchmark]
    public List<string> CollectionExpression()
    {
        return
        [
            "Apple",
            "Banana",
            "Orange",
        ];
    }

    [Benchmark]
    public List<string> CopyConstructor_Array()
    {
        return new List<string>(_dataAsArray);
    }

    [Benchmark]
    public List<string> CopyConstructor_Iterator()
    {
        return new List<string>(GetDataAsIterator());
    }

    [Benchmark]
    public List<string> ManuallyAdd_NoCapacitySet()
    {
        List<string> list = [];
        list.Add("Apple");
        list.Add("Banana");
        list.Add("Orange");
        return list;
    }

    [Benchmark]
    public List<string> ManuallyAdd_CapacitySet()
    {
        List<string> list = new(3);
        list.Add("Apple");
        list.Add("Banana");
        list.Add("Orange");
        return list;
    }
} Note in the above code example the baseline we will be comparing against is what I consider the traditional collection initializer: return new List<string>()
{
    "Apple",
    "Banana",
    "Orange",
}; The List Benchmark Results And of course, I wouldn’t make you go compile and run these yourself, so let’s look at the results below: Let’s go through the results from worst to best based on the Ratio column (Higher is worse): 3.31X – Using a copy constructor where we pass in an iterator is the worst performing. This is likely due to the overhead of creating an iterator, especially for such a small and simple overall operation AND because there’s no known capacity when using an iterator. 1.76X – Using a copy constructor even with an array isn’t great. If you know what you need to put into the collection, you’re better off using a normal classic collection initializer. An argument for both the copy constructors though is that if this isn’t on the hot path it might be more maintainable in your code to copy a collection vs instantiate it with duplicated values manually. 1.10X – Manually adding things to a collection without setting a capacity is only a little bit slower than using a collection initializer with no capacity! 10% slower based on these benchmarks. 1.0X – The baseline here is a classic collection initializer with no capacity set Here is where we start to see some speed up! 0.64X – Using a collection expression was 64% of the time! That’s a pretty dramatic improvement for what just looks like a syntax change, and that’s very much inline with what Dave Callan’s screenshot shows. 0.61X – Manually adding things to a list that has an initial capacity is actually FASTER than these other collection initializers and collection expression that we’ve seen so far! 0.53X – Using a classic collection initializer but providing the capacity is almost HALF the time! One of the common themes here is that providing a capacity is a BIG performance gain. We realized an ~87% gain over our baseline simply by providing it a capacity. Side note: why couldn’t the compiler do some kind of optimization here if we know the collection size in the braces?! Exploring Dictionary Collection Initializer Performance in C# Dictionaries don’t yet have a fancy collection expression that uses square brackets and removes even more bloat, but we do have several variations of collection initializers to use. These benchmarks will be very similar, also using BenchmarkDotNet, and they also use the same entry point program — so I won’t repeat it here. I know dictionaries can have two types to work with, and I wanted to keep this similar to the list example — not because they are similar implementations of collections, but because I didn’t want to just pollute this article with more variations of things for no reason. I decided to go with a where the keys are what we already looked at, and the values are just some short strings to work with that are unique. Dictionary<string, string> The Dictionary Benchmark Code Here’s the code for the dictionary benchmarks: [MemoryDiagnoser]
[MediumRunJob]
public class DictionaryBenchmarks
{
    private static readonly Dictionary<string, string> _sourceData = new()
    {
        ["Apple"] = "The first value",
        ["Banana"] = "The next value",
        ["Orange"] = "The last value",
    };

    private static IEnumerable<KeyValuePair<string, string>> GetDataAsIterator()
    {
        foreach (var item in _sourceData)
        {
            yield return item;
        }
    }

    [Benchmark(Baseline = true)]
    public Dictionary<string, string> CollectionInitializer_BracesWithoutCapacity()
    {
        return new Dictionary<string, string>()
        {
            { "Apple", "The first value" },
            { "Banana", "The next value" },
            { "Orange",  "The last value" },
        };
    }

    [Benchmark]
    public Dictionary<string, string> CollectionInitializer_BracesWithCapacity()
    {
        return new Dictionary<string, string>(3)
        {
            { "Apple", "The first value" },
            { "Banana", "The next value" },
            { "Orange",  "The last value" },
        };
    }

    [Benchmark]
    public Dictionary<string, string> CollectionInitializer_BracketsWithoutCapacity()
    {
        return new Dictionary<string, string>()
        {
            ["Apple"] = "The first value",
            ["Banana"] = "The next value",
            ["Orange"] = "The last value",
        };
    }

    [Benchmark]
    public Dictionary<string, string> CollectionInitializer_BracketsWithCapacity()
    {
        return new Dictionary<string, string>(3)
        {
            ["Apple"] = "The first value",
            ["Banana"] = "The next value",
            ["Orange"] = "The last value",
        };
    }

    [Benchmark]
    public Dictionary<string, string> CopyConstructor_Dictionary()
    {
        return new Dictionary<string, string>(_sourceData);
    }

    [Benchmark]
    public Dictionary<string, string> CopyConstructor_Iterator()
    {
        return new Dictionary<string, string>(GetDataAsIterator());
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAdd_NoCapacitySet()
    {
        Dictionary<string, string> dict = [];
        dict.Add("Apple", "The first value");
        dict.Add("Banana", "The next value");
        dict.Add("Orange", "The last value");
        return dict;
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAdd_CapacitySet()
    {
        Dictionary<string, string> dict = new(3);
        dict.Add("Apple", "The first value");
        dict.Add("Banana", "The next value");
        dict.Add("Orange", "The last value");
        return dict;
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAssign_NoCapacitySet()
    {
        Dictionary<string, string> dict = [];
        dict["Apple"] = "The first value";
        dict["Banana"] = "The next value";
        dict["Orange"] = "The last value";
        return dict;
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAssign_CapacitySet()
    {
        Dictionary<string, string> dict = new(3);
        dict["Apple"] = "The first value";
        dict["Banana"] = "The next value";
        dict["Orange"] = "The last value";
        return dict;
    }
} You’ll notice two themes creeping up: We have two different flavors of collection initializers: square brackets and curly braces We can manually instantiate a dictionary by adding or directly assigning (which are NOT the exact same behavior) Otherwise, we still have capacity considerations just like the list benchmarks! The Dictionary Benchmark Results The dictionary benchmarks are as follows: Doing the same exercise of highest to lowest ratio: 2.03X – Copy constructor with iterator strikes again! I suspect for similar reasons — no count for knowing the capacity and the overhead of creating the iterator relative to the number of items. 1.02X – Manually adding items to the dictionary WITH the capacity set was almost the exact same performance as using the collection initializer! This one to me is very surprising given the known capacity usually speeds things up a great deal. 1.0X – Our classic collection initializer using curly braces and not setting the capacity is our baseline Everything beyond here is technically faster according to our benchmarks: 0.96X – In the case where we provide a capacity, we’re a little bit faster than the baseline using the same syntax. 0.95X – Manually assigning items without a known capacity is even faster, and about 5% faster than the baseline. I still wouldn’t be making much of a fuss here. 0.94X – Classic collection initializer but using square brackets and not setting a capacity is ~6% faster than the baseline. 0.90X – Manually assigning items when the capacity is known is ~11% faster than the baseline, so we’re starting to pick up steam a little bit here! 0.87X – Classic collection initializer but using square brackets WITH a known capacity is ~15% faster than the baseline 0.86X – Manually adding things to the dictionary but NOT setting a capacity is ~16% faster… Okay, wait a second. Now we’re going to see that doing a dictionary copy is the FASTEST with a ~35% speed boost? I’m not sure how we’ve started to see known capacities not helping and copy constructors being fastest. Even I’m skeptical now. So I wanted to rerun the benchmarks and I wanted to add a variant of each of the manual benchmarks that uses instead of an empty . new() collection expression, [] In this run of the benchmarks, things are much closer across the board. I don’t think that discredits the previous benchmarks, because truly many of them were also relatively close with the iterator copy constructor remaining the huge outlier. But the other huge outlier that remains is the copy constructor using another dictionary! My takeaway is this: For the marginal boost in performance, I think you should opt for readability here — especially when the collection sizes are this small. If you know that you’re trying to set up a dictionary to be just like another, apparently copying it is much faster. So if you have this kind of thing on a hot path, here’s a fun little micro-optimization. Are These Realistic Benchmarks? I’ve written hundreds of articles, made hundreds of YouTube videos, and more posts across social media platforms than I could ever count. There will be people who want to pick these benchmarks apart, and unfortunately, their goal will seem like they’re just trying to discredit what’s being presented. However, I *DO* think it’s important to discuss the context of the benchmarks and look at what’s being considered in these scenarios: In the grand scheme of things, I’d suspect it’s unlikely that you’re going to get huge performance gains from focusing on these collection initializers. There’s probably bigger fish to fry in your code. But we do see there are some gains to be had! When using an iterator example with a very small set of data or other very fast operations, the overhead of the iterator itself may dwarf some of the other actions taking place The use case for these different ways of creating lists varies. For some, we’re defining the full collection whereas for others we’re using values from another collection. The use case isn’t necessarily apples to apples for a comparison. There seem to be big gains from knowing the capacity up front, which is likely helping reduce collection resizing behind the scenes. How might this change if we were dealing with larger data sets? The goal of presenting these benchmarks is not to tell you that you must do things a certain way — it’s simply to show you some interesting information. Even if you are hyper-focused on performance, you should benchmark and profile your own code! Don’t rely on my results here. Let these serve as a starting point that you might be able to tune things on your hot path that you didn’t realize. What other considerations can you think of? Feel free to share in the comments — but be conversational, please. Wrapping Up Collection Initializer Performance in C# Overall, I consider most of what we see in this article on collection initializer performance in C# to be micro-optimizations — more than likely. I wouldn’t lose sleep over using one way over another, as long as you’re optimizing for readability and your profiling results don’t show you spending most of your time doing collection initialization. I hope that you got to have fun exploring this with me and see that if you’re ever curious you can go set up some simple benchmarks to experiment! If you found this useful and you’re looking for more learning opportunities, consider and check out my ! subscribing to my free weekly software engineering newsletter free videos on YouTube

Get An 87% Boost to Collection Initializer Performance in C#

Stories, News & Mentions about CUELY

Cuely’s Stories on HackerNoon