Speaker 1: Welcome to the dep dive. We're jumping straight into C
Speaker 1: Sharp twelve and dot Net eight today.
Speaker 2: Yeah, a real powerhouse duo.
Speaker 1: Definitely for building modern apps that well run pretty much anywhere.
Speaker 1: Our mission here is to kind of extract the essentials
Speaker 1: you need to navigate this stuff exactly.
Speaker 2: We're drawing from a pretty comprehensive resource on C Shark
Speaker 2: twelve and dot eight.
Speaker 1: Consider this your shortcut right setting up your dev playground,
Speaker 1: getting the Sea Shark basics.
Speaker 2: And exploring those core programming ideas all within this latest
Speaker 2: dot net evolution.
Speaker 1: Okay, let's unpack it. First things first, getting set up,
Speaker 1: choosing your environment right.
Speaker 2: The big two are Visual Studio twenty twenty two and Visual.
Speaker 1: Studio Code Yeah vs. Twenty twenty two, hugely popular with
Speaker 1: pro dot net devs, especially if you're mainly on Windows.
Speaker 2: It's that full ide experience right out of the.
Speaker 1: Box exactly guides you through set up you know, Sea
Speaker 1: Shark settings, choosing your theme, which is surprisingly important.
Speaker 2: Oh yeah, staring at it all day, you want it
Speaker 2: to look right. Uh.
Speaker 1: True, It's packed with features, so if you're deep Windows
Speaker 1: want that all in one feel. Vs. Twenty twenty two
Speaker 1: is probably your best.
Speaker 2: Bet, but then you've got Visual Studio Code the contrast. Yeah,
Speaker 2: it's big selling point is flexibility runs everywhere Windows, Mac, Linux, Yeah,
Speaker 2: even arm chips like Apple Silicon or Raspberry Pie.
Speaker 1: Super lightweight design too, right, And for.
Speaker 2: Dot network in vs code, the c Shark DevKit extension
Speaker 2: is well essential.
Speaker 1: Ah yeah, tell us about that.
Speaker 2: It brings in the features you need for like managing
Speaker 2: solutions with multiple projects. Really turns vs code into a
Speaker 2: proper dot net environment.
Speaker 1: So if you valued that cross platform agility and maybe
Speaker 1: work across different ocs.
Speaker 2: Or you just prefer a more modular, bill it yourself
Speaker 2: kind of.
Speaker 1: Editor, vs code with the DevKit is a strong contender totally.
Speaker 2: They even have that insider's version if you like living
Speaker 2: on the edge getting new features early.
Speaker 1: Okay, So organizing projects this idea of a solution.
Speaker 2: Yeah, that's key in both Visual Studio and vs code
Speaker 2: with the DevKit.
Speaker 1: Think of it like a binder, right, holding all your
Speaker 1: related projects together.
Speaker 2: Exactly your website code, maybe a class library, a console app.
Speaker 2: The solution file groups them. Let's the tools manage them
Speaker 2: as one unit.
Speaker 1: Our source mentions a chapter one solution holding a Hello
Speaker 1: CS project.
Speaker 2: Classic example, and that ties into the dot Net SDK,
Speaker 2: the Software.
Speaker 1: Development kit, which gives you the command line interface the CLI.
Speaker 2: Right fundamental for creating and managing projects. No matter which
Speaker 2: editor you use.
Speaker 1: You can use the CLI to spin up a new
Speaker 1: console app, for instance, yep.
Speaker 2: And it generates those basic files, the dot c Proja
Speaker 2: project file program.
Speaker 1: Dot cs and those bin and obj folders you see
Speaker 1: pop up, and.
Speaker 2: The c sharp DevKit in vs code just picks up
Speaker 2: those solution files and knows what to do.
Speaker 1: So the CLI is kind of the bedrock. Interacting with
Speaker 1: the core.
Speaker 2: Tools absolutely and understanding solutions is vital as your apps
Speaker 2: get bigger, more complex, maybe split into different parts.
Speaker 1: Okay, let's actually build something super basic, a console app.
Speaker 2: Walk is through it right.
Speaker 1: You typically use a template, right, the c shark console
Speaker 1: app template yep.
Speaker 2: Give it a project name.
Speaker 1: Like hellocs, choose where to save it maybe CR twelve, dot.
Speaker 2: Net eight, and name the solution like chapter one.
Speaker 1: And there's that interesting option mentioned about disabling native aot publish.
Speaker 2: Yah ahead of time compilation piles straight to machine code.
Speaker 1: Faster startup, smaller size in some cases, but we'll park
Speaker 1: that for now. It's covered later right.
Speaker 2: So once you create the project.
Speaker 1: You get this program dot cs file and it's usually
Speaker 1: super simple at first.
Speaker 2: Often just a comment and maybe one line of code
Speaker 2: like console right line.
Speaker 1: It's deliberately minimal, a clean slate.
Speaker 2: And a good place to start poking around, like finding
Speaker 2: out the name space of that default program class.
Speaker 1: Oh right, the source had that snippet type of program
Speaker 1: dot namespace.
Speaker 2: String nameycal type of program dot namespace none, console right
Speaker 2: line namespace dot e something like that.
Speaker 1: Just a handy way to see how your code's.
Speaker 2: Organized, definitely, and you can take that further, get environment
Speaker 2: info like the current director jarn director yeah, or the OS.
Speaker 1: Version environment do OS version version string in that name space.
Speaker 2: Again, just useful for seeing where your code is actually running.
Speaker 2: Good for debugging, like.
Speaker 1: A quick health check of the environment.
Speaker 2: Exactly what OSM I on? Where are my files? Useful stuff.
Speaker 1: One last dev environment tip. They mentioned inline hints or
Speaker 1: inlay hints.
Speaker 2: Oh, those are great little reminders right in the code.
Speaker 1: Yeah, they show the parameter names when you're calling a method, so.
Speaker 2: You don't have to keep jumping back to the definition exactly.
Speaker 1: Saves a lot of cognitive load. You can turn them
Speaker 1: on in VS twenty twenty two's options.
Speaker 2: Tools, Options text Editor, c shap advanced inline hints somewhere
Speaker 2: in there.
Speaker 1: And in VS code you just search settings for inline hints.
Speaker 2: Small feature, big impact on readability.
Speaker 1: Sometimes totally agree. Okay, moving on C sharp fundamentals, grammar, vocabulary,
Speaker 1: the building blocks.
Speaker 2: Right, So the C shark compiler is called Roslin.
Speaker 1: Think of Roslyn as the translator takes your C sharp.
Speaker 2: And turns it into intermediate language.
Speaker 1: Which gets stored in assemblies of those DLL or ex
Speaker 1: files YEP package code.
Speaker 2: Then the dot Net run times Virtual Machine core CLR
Speaker 2: that's the engine kinda it uses it just in time,
Speaker 2: or JIT compiler.
Speaker 1: Which translates that IL into.
Speaker 2: Native CPU instructions. The stuff your actual process or understands
Speaker 2: happens at runtime.
Speaker 1: So C sharp to IL with Roslin, then IL to
Speaker 1: native code with the JIT and core CLR.
Speaker 2: You got it. It's a neat separation. Let's see sharp
Speaker 2: evolve kind of independently from the runtime details helps with
Speaker 2: cross platform two makes sense.
Speaker 1: Now, C sharp grammar, we're talking statements.
Speaker 2: Blocks, code inside curly braces and comments crucial for explaining things.
Speaker 2: But the advice is, yeah, the implicitly or globally imported.
Speaker 2: Saves you typing using system or using system dot collections
Speaker 2: generic all the time.
Speaker 1: Where does that info live?
Speaker 2: It's generated in that of data bug Net eight point
Speaker 2: zero folder, usually in a dot global usings dot g
Speaker 2: dot c s file. We're similar.
Speaker 1: So for basic console app Microsoft dot net SDK, you
Speaker 1: get systemsystem, dot io, system dot.
Speaker 2: Link common stuff, and if it's a web project Microsoft
Speaker 2: dot net sdk web you get more like asthmiccore stuff
Speaker 2: net dot HGDP Jason.
Speaker 1: It's just about reducing boilerplate, making common types easy to.
Speaker 2: Access precisely, less clutter, focus on your.
Speaker 1: Logic, and finally literals simple concepts.
Speaker 2: Yeah, just the way you write fixed values directly in
Speaker 2: your code, like the number.
Speaker 1: One, two, three, or the text hello or true.
Speaker 2: False, exactly the raw value itself written in the source.
Speaker 1: All right, let's talk about scoring different kinds of data,
Speaker 1: starting with texts.
Speaker 2: Okay, so the basic unit is char for a single character.
Speaker 1: But there's a catch with unicode.
Speaker 2: Uh huh. Some characters, especially emojis, are less common. Symbols
Speaker 2: might actually need two char values called surrogate.
Speaker 1: Pairs, so one visual character doesn't always equal one char variable.
Speaker 2: Exactly something to be aware of if you're doing low
Speaker 2: level text manipulation. Got to handle Unicode properly.
Speaker 1: Good point.
Speaker 2: What about numbers, lots of options. For whole numbers, you've
Speaker 2: got integers, int is common handles positive and negative, int
Speaker 2: is unsigned only.
Speaker 1: Positive, and for numbers with decimal points.
Speaker 2: Floating point types float, you need an F suffix like
Speaker 2: three point one forty f and double, which is the
Speaker 2: default if you just right say three point one.
Speaker 1: Four, and then there's decimal for high precision.
Speaker 2: Right crucial for financial stuff yeh, where tiny rounding errors
Speaker 2: are bad news. Use an M suffix like twelve point
Speaker 2: nine to nine ter.
Speaker 1: So the difference is memory, use range of values and
Speaker 1: that precision.
Speaker 2: Aspect spot on integers for whole numbers, floats doubles for
Speaker 2: general fractional numbers, decimal for exact decimal.
Speaker 1: Representation, and we can check their size yep.
Speaker 2: Using the size operator tells you how many.
Speaker 1: Bites they take up, and find their limit.
Speaker 2: Mind value and max value properties on the types themselves,
Speaker 2: like into dot minvalue, double dot max value.
Speaker 1: The source had that classic point one plus point two.
Speaker 2: Example, right, yeah, showing how double might give you point
Speaker 2: three zero zero zero zero zero zero zero zero zero
Speaker 2: zero four. Well, decimal gives you exactly point three. It's
Speaker 2: because of how they store the numbers internally.
Speaker 1: Fascinating. That precision difference is huge sometimes.
Speaker 2: It really can be. Understanding the tradeoffs is important.
Speaker 1: What about those huge integer types in one two eight.
Speaker 2: H yeah, system dot in one two eight and U
Speaker 2: twenty two eight added in dot net seven massive sixteen
Speaker 2: byte integers.
Speaker 1: But using size klanumum is.
Speaker 2: Tricky, requires unsafe code and a compiler flag. Definitely an
Speaker 2: advanced feature for specialized needs like really big numbers and calculations.
Speaker 1: Got it back to basics. String for text.
Speaker 2: YEP sequences of characters pretty straightforward, has a length property.
Speaker 1: And they're immutable. Right. You can't change a string once
Speaker 1: it's created.
Speaker 2: Correct. Operations that look like they modify a string actually
Speaker 2: create a new string. Important for performance if you're doing
Speaker 2: tons of manipulation.
Speaker 1: Okay, now var the keyword var?
Speaker 2: Oh yeah, tech difference superhandy.
Speaker 1: What's the compiler figure out the type exactly?
Speaker 2: Instead of string message hi, you can just write var
Speaker 2: message hi and.
Speaker 1: The editor usually shows you what type it an YEP.
Speaker 2: Hover over var and it'll tell you a string.
Speaker 1: Makes code shorter, but maybe less explicit.
Speaker 2: Sometimes it's a balance. Great for complex tykes where spelling
Speaker 2: it out is noisy, but sometimes being explicit makes things clearer.
Speaker 1: Use it wisely, right, Okay, back to console apps.
Speaker 2: For a sec text based run from the command line.
Speaker 1: Good for scripts, simple tools, learning.
Speaker 2: And importantly they can take arguments from the command line.
Speaker 1: We'll get to that first. Making the output look nice.
Speaker 1: String formatting several ways to do it.
Speaker 2: The classic placeholders console right line.
Speaker 1: Name, name, age aw that style yep.
Speaker 2: Or you can use named arguments for clarity, especially with
Speaker 2: multiple parameters of the same type.
Speaker 1: Like console dot right line arg one first R one
Speaker 1: second right.
Speaker 2: The source also mentioned boxing warnings.
Speaker 1: Yeah said it's more unity thing less critical for general
Speaker 1: dot net apps covered here.
Speaker 2: Okay, big one though.
Speaker 1: Yeah.
Speaker 2: Culture's impact on formatting.
Speaker 1: Oh yeah, numbers, dates, currency, They look different depending on
Speaker 1: region settings.
Speaker 2: Five versus doc A, comma versus dot for one thousand separators.
Speaker 1: But you can control it.
Speaker 2: Yeah, definitely specify a culture like culture info invariant culture
Speaker 2: for consistent machine readable formats, or.
Speaker 1: Use custom format strings like zero for zero, placeholder hashtag
Speaker 1: for digit exactly.
Speaker 2: Table two point eight in the source has details lots
Speaker 2: of control.
Speaker 1: There, and the easiest way often is string interpolation. The
Speaker 1: dollar sign syntax.
Speaker 2: Variable yep usually much cleaner. Console right line.
Speaker 1: H reads nicely okay, nullable reference types nrts. Big change
Speaker 1: in modern C sharp.
Speaker 2: Huge designed to tackle those dreaded noull reference exception errors.
Speaker 1: By adding a question mark spring right.
Speaker 2: It tells a compiler this variable might be null, and.
Speaker 1: The compiler then warns you if you try to use
Speaker 1: it without checking exactly.
Speaker 2: It performs static analysis to find potential null issues before
Speaker 2: you run. The code makes things much safer.
Speaker 1: But you still have to handle the null case right.
Speaker 1: The knot is a warning system precisely.
Speaker 2: It forces you to think about nulls, but you still
Speaker 2: need if my string null checks or similar patterns. It
Speaker 2: doesn't magically fixed nulls. It makes them explicit. Got it?
Speaker 1: Okay? Command line arguments? How do we get those?
Speaker 2: When you run your app like dot Net, run first arg, second.
Speaker 1: Arc Those first arg second arg pieces.
Speaker 2: They get passed into your main method as an array
Speaker 2: of strings, usually called arcs string arcs.
Speaker 1: So urg zero would be first RG, ARGs one would
Speaker 1: be second arc yep.
Speaker 2: You can move through the arg's array and use those
Speaker 2: values to change how your app behaves. Super useful for
Speaker 2: making tools flexible makes.
Speaker 1: Sense, and that platform specific example, setting cursor size.
Speaker 2: Right works on Windows throws an exception on MCLINICX A.
Speaker 1: Good reminder that even with cross platform dot net, the
Speaker 1: underlying OS still matters.
Speaker 2: Sometimes absolutely, and the solution often a tricatch block.
Speaker 1: Try to set the cursor size, catch the exception if
Speaker 1: it fails on Linux or Mac exactly.
Speaker 2: Graceful handling of platform difference. We'll dig more into trycatch soon.
Speaker 1: Perfect segue. Let's move into core programming concepts, starting with operators.
Speaker 2: Basic math, your bread butter plus AA for AD, subtract
Speaker 2: multiplied divide and per modulo the remainder after division ten
Speaker 2: percent three is one?
Speaker 1: Got it? Logical operators and for a ing for R
Speaker 1: and they have that short circuiting behavior.
Speaker 2: Yeah, that's important. With Andy in if the left side
Speaker 2: is false, it doesn't even look at the right.
Speaker 1: Side because the whole thing must be false anyway, right And.
Speaker 2: With Andy and if the left side is true, it
Speaker 2: skips the right side because the whole thing must be true.
Speaker 1: Good for performance avoids unnecessary.
Speaker 2: Work usually, but be careful if the right side expression
Speaker 2: has side effects you rely on happening.
Speaker 1: Like calling a function that's supposed to always log something
Speaker 1: it might get skipped exactly.
Speaker 2: Can lead to subtle bugs, something to be aware of, okay.
Speaker 1: Making decisions.
Speaker 2: Switch statements a way to handle multiple choices based on
Speaker 2: a single value, cleaner than lots of if l's ifs.
Speaker 1: Sometimes you have case labels for specific values, a default
Speaker 1: case for everything else, and C shark allows go to
Speaker 1: within a switch jump to other cases.
Speaker 2: It does. Yeah, use with caution, though can make code
Speaker 2: harder to follow if overused.
Speaker 1: Right and then There are switch expressions in newer C
Speaker 1: sharp versions.
Speaker 2: Yeah, C sharp eight onwards. More concise, often more powerful,
Speaker 2: especially with pattern matching.
Speaker 1: That example with animals was cool checking the type and properties.
Speaker 2: Cat four legged cat when four leggd cat legs equals.
Speaker 1: Four that kind of thing, or just matching the type
Speaker 1: cat cat or property pattern spider spider when Spider's poisonous.
Speaker 2: Handling null using the discard as a default, very expressive,
Speaker 2: often leads to cleaner code for complex conditions.
Speaker 1: Definitely looks more functional, more declarative.
Speaker 2: It leans that way, Yeah, okay. Storing collections a raise
Speaker 2: the basic fix size collection string names, new string three.
Speaker 1: Create space for three strings, access them with indices starting
Speaker 1: at zero always.
Speaker 2: Zero based name zero, names one, names two.
Speaker 1: And loop through them with a four loop and the
Speaker 1: link property.
Speaker 2: I names length iplus plus new names standard stuff.
Speaker 1: What about those inline arrays and c share twelve ah
Speaker 1: more of.
Speaker 2: An advanced behind the scenes performance thing for the runtime team.
Speaker 1: Mostly so not something you typically declare yourself in application code.
Speaker 2: Probably not directly no, but you might benefit from libraries
Speaker 2: using them under the hood. There's a link if you
Speaker 2: want the deep dive on those.
Speaker 1: Gotcha and formatting output again.
Speaker 2: Aligning column yeah, index alignment yeah, like zero zero twelve
Speaker 2: pads with spaces to align right in a twelve.
Speaker 1: Character call, and showing binary index ed format string.
Speaker 2: Like zero three four point b three two shows a
Speaker 2: number is thirty two bits. Binary representation potentially padded useful
Speaker 2: for low level inspection.
Speaker 1: Okay, getting data in parsing strings to numbers.
Speaker 2: Or dates, big parse, daytime dot parse common methods, but they.
Speaker 1: Can fail throw exceptions at the string. Isn't it right?
Speaker 2: Yep, format exception. That's why culture matters too, cultureinfo dot
Speaker 2: invariant culture to avoid nasty surprises with different date or
Speaker 2: number formats.
Speaker 1: So the safer way is tripars.
Speaker 2: Generally yes. In trpars input string out in a result,
Speaker 2: it returns true or.
Speaker 1: False, true if it worked, and the result variable gets.
Speaker 2: The value false if it failed, and result gets a
Speaker 2: default value like zero for end no exception thrown.
Speaker 1: Much cleaner for handling potentially bad user input avoids the
Speaker 1: overhead of exceptions for expected failures.
Speaker 2: Exactly use pars when you're sure the input is valid.
Speaker 2: Trypars when it might not be.
Speaker 1: And if parse does thrown exception or something else goes wrong.
Speaker 1: That's where tricatch finally comes in.
Speaker 2: Right wrap the risky code in try.
Speaker 1: Handle specific errors in catch format exception x or.
Speaker 2: More general errors in catch. Oh, I say, and use
Speaker 2: finally for cleanup. Code that always.
Speaker 1: Runs, always runs, whether an exception happen or not, whether
Speaker 1: it's caught or not. Good for releasing resources like closing files.
Speaker 1: Essential for robust code.
Speaker 2: Okay, integer overflow numbers getting too.
Speaker 1: Big Yeah by default se sharp injurer math is unchecked.
Speaker 1: If indemac's value plus one happens, it wraps around silently
Speaker 1: to int men value.
Speaker 2: Which can cause very weird bugs.
Speaker 1: Totally, so you can use the checked keyword.
Speaker 2: Either as a block yeah result large number one plus
Speaker 2: large numb.
Speaker 1: Two, or as compiler option for the whole project.
Speaker 2: And if overflow happens inside a checked context.
Speaker 1: It throws an overflow exception instead of wrapping silently makes
Speaker 1: the error obvious.
Speaker 2: There's a slight performance cost, but often worth it for correctness.
Speaker 1: Definitely something to consider, especially with financial or critical calculations.
Speaker 1: All right, getting near the end functions or methods in
Speaker 1: C sharp reusable blocks of code key for organization. The
Speaker 1: example was time stable took a required number.
Speaker 2: And an optional sized parameter with a default value void.
Speaker 2: Time stable INNT number in size.
Speaker 1: Is twelve, meaning you can call it with just the
Speaker 1: number time stable five and size default.
Speaker 2: To twelve, or provide both time stable five twenty.
Speaker 1: And using named arguments makes calls clearer. Time stable number
Speaker 1: five size twenty.
Speaker 2: Especially useful when there are multiple optional parameters or parameters
Speaker 2: of the same type. Improves readability quick terminology.
Speaker 1: Check parameter versus argument.
Speaker 2: Parameter is the variable in the function definition in number
Speaker 2: in size. Argument is the actual value passed in when
Speaker 2: you call the function five twenty.
Speaker 1: Got it and functions can return values too.
Speaker 2: Of course, the calculator tax example took an amount and reagencode.
Speaker 1: Used to switch expression based on the region.
Speaker 2: And return the calculated decimal tax value return calculated tax.
Speaker 1: Perfect for encapsulating a calculation.
Speaker 2: Or rule absolutely and documenting these functions.
Speaker 1: XML comments Yeah, those triple slash comments summary summary editors.
Speaker 2: Pick those up and show them as tooltips when you're
Speaker 2: calling the function.
Speaker 1: Explains what it does, parameters, return value. Huge help for maintainability,
Speaker 1: good practice definitely.
Speaker 2: Lastly, that decline larrative versus imperative style comparison.
Speaker 1: Using the Fibonacci sequence.
Speaker 2: Fib functional usercursion and a switch expression describing what fibonacci is.
Speaker 1: While fib imperative used a loop describing how to calculate
Speaker 1: it step by step.
Speaker 2: Just shows there are different ways to think about and
Speaker 2: solve problems in code. Neither is always better, depends on
Speaker 2: the context.
Speaker 1: A good illustration of different paradigms yep.
Speaker 2: Functional style often emphasizes immutability in expressions. Imperative focuses on
Speaker 2: mutable state and step by step instructions. Wow.
Speaker 1: Okay, that was quite the journey through the fundamentals.
Speaker 2: We covered a lot. Setting up the environment vs versus
Speaker 2: vs code.
Speaker 1: See shirt grammar, Roslin, il jit, data types like char, int, decimal, string, Nobel.
Speaker 2: Types, operators, switch statements and expressions, arrays, parsing, exception handling
Speaker 2: with trycatch.
Speaker 1: Checked overflow, basic functions, parameters versus arguments, returning values, XML comments,
Speaker 1: and even a peak at programming styles.
Speaker 2: Phew. Yeah, these really are the core building blocks you
Speaker 2: need for getting started with c SHAR twelve and dot
Speaker 2: net eight.
Speaker 1: Having a solid grasp of this stuff is just crucial
Speaker 1: for building anything substantial and reliable.
Speaker 2: Couldn't agree more. It's the foundation for everything else.
Speaker 1: So as you the listener, continue exploring this, maybe something
Speaker 1: specific caught your ear.
Speaker 2: Perhaps nullable reference types, or you want to know more
Speaker 2: about collection types beyond arrays like lists or dictionaries, or maybe.
Speaker 1: The details of the Roslin compiler or the subtleties of
Speaker 1: decimal versus double.
Speaker 2: Yeah, the point is mastering these fundamentals really opens the
Speaker 2: door to the more advanced, powerful features of dot net, so.
Speaker 1: We definitely encourage you dive deeper. Check out the links,
Speaker 1: explore the official documentation. This platform is incredibly rich and
Speaker 1: constantly evolving. There's always more to learn.