I have a little hard time with all of those design patterns and things that could help me write maintainable code, clean and reusable.What are the most used design patterns in your Apps? A list or something with them will be nice, there are a lot of design patterns and I dont really know with what should I start.
You don't have to consider that much about design patterns if you follow 'Laravel' pre-defined way. they kinda have defined almost everything by following those design patterns.
You can refer these articles as a start.
https://github.com/alexeymezenin/laravel-best-practices
https://www.innofied.com/top-10-laravel-best-practices/
And most importantly Official documentation.
https://laravel.com/docs/7.x
The most import thing you need to consider when using 'Laravel' try to use 'Laravel' as much as possible. (Instead of pure php)
Related
I'm reading about the Laravel Best practices to reduce the code duplication as much as I can, then I read about the repository pattern and I'm following this technique but when I was exploring the https://github.com/akaunting/akaunting open source software for accounting, I saw there is nothing related to respository pattern. I really got confused, so when should I use the repository pattern? if it is helpful when why the good projects not use that pattern? or if there is something better than repository pattern?
This is true for every design pattern: never start with wanting to implement a specific design pattern.
Start by never using the repository pattern (or any other pattern) and when you feel like your controllers are getting really big or your code is getting really hard to maintain take a look at what design pattern might solve your issue.
The given package does not contain that pattern because the people who made it did not need an extra layer of abstraction or chose other abstraction solutions.
Always start simple.
In my experience code behind UI can easily get ugly, and inorganized, e.g. long functions, lots of variables etc.
How do you manage the code behind UI?
The MVC pattern is often used to impose some structure and organisation.
Following the principles of SOLID OO design and similar ideas helps.
It depends on your programming-language.
Threre are a lot of QA-Tools for different languages. Have a look at wikipedia
Which languages and techniques do you use?
One solution is to use 'immediate mode' UIs. It basically boils down to only caring about the UI element you're currently focussed on and binding the variables with data-side app variables. This is the opposite of retention mode UIs
Great video here.
FxCop thought me (basically, from memory) that functions, classes and properties should be written in MajorCamelCase, while private variables should be in minorCamelCase.
I was talking about a reasonably popular project on IRC and quoted some code. One other guy, a fairly notorious troll who was also a half-op (gasp!) didn't seem to agree. Everything oughta be in the same casing, and he quite fervently favored MajorCamelCase, or even underscore_separation.
Ofcourse, he was just a troll so I reckoned I'd just keep doing it the way I already did. Before I learned the above guidelines, I hardly even had a coherent naming style.
He got me thinking, though -- does stuff like this really matter?
You need to make sure that your code is readable in the future. Please remember that you might want to pass the development of your application to someone else and this person will need to read and understand it. You could stop actively working on a project and return to it after a year - and be suprised that you have to read code carefully to understand how it works.
I believe it was Steve McConnell who said that specific naming style does not really matter (you could use anything you want as long as you are consistent) but this only applies when everyone working on the project agree with you.
In general it is better to adopt community-accepted coding styles where possible to facilitate code reuse and shorten learning curves.
If you don't care about long-term maintanability of your project (or consistency or readability) then no, casing (and coding conventions in general) don't really matter. Otherwise, they do matter. See this.
Your specific coding style doesn't matter (much), so long as it is consistent throughout the project.
This improves readability and understanding, as if an identifier is named in a particular way, the reader can (hopefully) be confident as to what that naming style implies.
As regards CamelCase v underscores, etc: again, it's down to your coding convention. One approach which uses both is to apply a prefix with underscore to indicate the module in which the function, or file-scope/global variable, is used, e.g. Config_Update(), Status_Get().
I'm running a refactoring code dojo for some coworkers who asked how refactoring and patterns go together, and I need a sample code base. Anyone know of a good starting point that isn't to horrible they can't make heads or tails of the code, but can rewrite their way to something useful?
I would actually suggesting refactoring some of your and your coworkers' code.
There are always places that an existing codebase can be refactored, and the familiarity with the existing code will help make it feel more like a useful thing and less like an exercise. Find something in your company's code to use as an example, if possible.
Here are some codes, both the original and the refactored version, so you can prepare your kata or simply compare the results once the refactoring is performed:
My books have both shorter examples and a longer, actually a book long example. Code is free to download.
VB Code Examples
C# Code Examples
A nice example from Refactoring Workbook
There are a lot of examples on the internet of simple games like Tic-Tac-Toe or Snake that have a lot of smells but are simple enough to start with refactoring.
The first chapter in Martin Fowler "Refactoring" is a good starting point to refactoring. I understood most of the concepts when one of my teachers at school used this example.
What is the general knowledge level of your coworkers?
Something basic as code duplication should be easy to wrap their heads around. Two pieces of (nearly) identical code that can be refactored into a reusable method, class, whatever. Using a (past) example from your own codebase would be good.
I would recommend you to develop a simple example project for a specific requirement.
Then you add one more requirement and make changes to the existing classes . You keep on doing this and show them how you are finding it difficult to make each change when the code is not designed properly. This will make them realize easily because, this is what those ppl will be doing in their day to day work. Make them realize that , if patterns and principles are not followed from beginning, how are they going to end up in mess at the end.
When they realize that,then you start from scratch or refactor the existing messed up code .Now add a requirement and make them realize that it is easy to make a change in the refactored code, so that you need to test only a few classes. One change would not affect others and so on.
You could use the computer ,keyboard and printer class as an example. Add requirements like, you will be wanting the computer to read from mouse , then one more requirement can be like your computer would want to save it in hard disk than printing. Finally your refactored code should be like, your computer class should depend on abstract input device class and output device class. And your keyboard class should inherit from Inputdevice class.
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin considers refactoring.
I'm loving Refactoring Guru examples.
In there you can find design patterns examples too.
Refactoring is non-functional requirement when code perform correct functionality for which it is designed however difficult to debug, requires more effort to maintain and some performance bottleneck. Refactoring is to change to be easily maintainable, good readability and improve efficiency.
Thus we need to focus on criteria to make code more readable, easy to maintain.
Its obvious that having very large method/function might be difficult to understand.
Class depends on other hundreds of class make thing worst while debugging.
Code should be readable just like reading some workflow.
You can also use tools like sonar which can help you to identify critical criteria such as "Cyclomatic Complexity"
http://www.sonarsource.org/managing-cyclomatic-complexity-to-increase-maintainability/
You ask them to write code them self and check how tool does refactoring.
Apart from that, you can write code in eclipse and there is option available which does refactoring for you...
It's a bit dated (2003), but IBM has several refactoring examples (that work[ed?] in Eclipse) at http://www.ibm.com/developerworks/library/os-ecref/
I am developing my first ASP.NET MVC application using the Entity Framework. I have no previous .NET experience, although I'm fluent in other OO languages. I am having trouble understanding Linq to Entity query expressions, more specifically its syntax and how to render the results on an ASP page.
For example, I am joining three tables (entities) together and trying to iterate over the results, but I get all sorts of type errors. Every example I find on Google, SO, or MSFT hasn't been straightforward and each site takes their own approach. I looked at the book Programming Entity Framework, but this too seems to be over my head at the moment.
I am looking for clear, concise examples of executing the equivalent of complex multiple joins and iterating over the results.
Thanks
I've just started this myself, and I bought both the wrox book and the o'reilly one.
I've found the wrox one a little more inaccessible - the language used in it is a bit heavier, and the layout/organisation isn't quite so 'flowy' (is that a word? hehe).
The o'reilly one on the other hand is a cracking read, and really does lead you nicely through it. It's available on safaribooks too if you have a sub, I got it from Amazon who seemed one of the few places to have it in stock. Very much recommended.
take a look at these samples - http://blogs.msdn.com/adonet/archive/2007/03/13/101-linq-samples-updated.aspx
i picked up the concept from these examples itself
Scott Guthrie's blog has also really good explanation & samples
Sounds to me like you should get yourself a good book on the subject. Since you have no previous experience in .NET a general book that covers LINQ might be a start and then a ASP.NET-MVC specific one.
Perhaps the reason why being fluent in "other" OO languages isn't helping is that LINQ isn't an OO language, its much more functional and therefore takes a different way of reasoning to understand well.