Search Results

Search found 13 results on 1 pages for 'dreza'.

Page 1/1 | 1 

  • Should interfaces inherit interfaces

    - by dreza
    Although this is a general question it is also specific to a problem I am currently experiencing. I currently have an interface specified in my solution called public interface IContextProvider { IDataContext { get; set; } IAreaContext { get; set; } } This interface is often used throughout the program and hence I have easy access to the objects I need. However at a fairly low level of a part of my program I need access to another class that will use IAreaContext and perform some operations off it. So I have created another factory interface to do this creation called: public interface IEventContextFactory { IEventContext CreateEventContext(int eventId); } I have a class that implements the IContextProvider and is injected using NinJect. The problem I have is that the area where I need to use this IEventContextFactory has access to the IContextProvider only and itself uses another class which will need this new interface. I don't want to have to instantiate this implementation of IEventContextFactory at the low level and would rather work with the IEventContextFactory interface throughout. However I also don't want to have to inject another parameter through the constructors just to have it passed through to the class that needs it i.e. // example of problem public class MyClass { public MyClass(IContextProvider context, IEventContextFactory event) { _context = context; _event = event; } public void DoSomething() { // the only place _event is used in the class is to pass it through var myClass = new MyChildClass(_event); myClass.PerformCalculation(); } } So my main question is, would this be acceptable or is it even common or good practice to do something like this (interface inherit another an interface): public interface IContextProvider : IEventContextFactory or should I consider better alternatives to achieving what I need. If I have not provided enough information to give suggestions let me know and I can provide more.

    Read the article

  • Should interfaces extend (and in doing so inherit methods of) other interfaces

    - by dreza
    Although this is a general question it is also specific to a problem I am currently experiencing. I currently have an interface specified in my solution called public interface IContextProvider { IDataContext { get; set; } IAreaContext { get; set; } } This interface is often used throughout the program and hence I have easy access to the objects I need. However at a fairly low level of a part of my program I need access to another class that will use IAreaContext and perform some operations off it. So I have created another factory interface to do this creation called: public interface IEventContextFactory { IEventContext CreateEventContext(int eventId); } I have a class that implements the IContextProvider and is injected using NinJect. The problem I have is that the area where I need to use this IEventContextFactory has access to the IContextProvider only and itself uses another class which will need this new interface. I don't want to have to instantiate this implementation of IEventContextFactory at the low level and would rather work with the IEventContextFactory interface throughout. However I also don't want to have to inject another parameter through the constructors just to have it passed through to the class that needs it i.e. // example of problem public class MyClass { public MyClass(IContextProvider context, IEventContextFactory event) { _context = context; _event = event; } public void DoSomething() { // the only place _event is used in the class is to pass it through var myClass = new MyChildClass(_event); myClass.PerformCalculation(); } } So my main question is, would this be acceptable or is it even common or good practice to do something like this (interface extend another an interface): public interface IContextProvider : IEventContextFactory or should I consider better alternatives to achieving what I need. If I have not provided enough information to give suggestions let me know and I can provide more.

    Read the article

  • Documenting and enforcing programming standards and guidelines for shared library

    - by dreza
    Myself and another developer with the go ahead from our IT director have started a general purpose library in .NET with the intention that it will provide many common purpose classes that we use in our day to day development. During discussions and design of the library we have come up with a set of standards that we want the library to follow to ensure it is maintained and expanded on in a consistent manner. What is the best way to ensure these decisions we made for the library get feed to the other developers who might be using and adding to this library in the future. One of our decisions was to ensure we review all checked in code so we expect initially there to be some differences in coding styles of individuals not fitting in with the project standards. Some ideas I had were: Add a Read-me.txt to the project that outline the guidelines and standards Send an email out to everyone in the team to let them know about the project etc Call a team meeting to go through this new project and our expectations and standards we were aiming to follow Try and enforce the standards via Visual Studio (not sure if this would be possible or how just an idea) At the moment there is no general company programming standards so this would be a first really insofar as we are creating a standard that different project teams would need to adhere to.

    Read the article

  • Separation of development responsibilities in a new project

    - by dreza
    We have very recently started a new project (MVC 3.0) and some of our early discussion has been around how the work and development will be split amongst the team members to ensure we get the least amount of overlap of work and so help make it a bit easier for each developer to get on and do their work. The project is expected to take about 6 months - 1 year (although not all developers are likely to be on and might filter off towards the end), Our team is going to be small so this will help out a bit I believe. The team will essentially consist of: 3 x developers (All different levels i.e. more senior, intermediate and junior) 1 x project manager / product owner / tester An external company responsbile for doing our design work General project/development decisions so far have included: Develop in an Agile way using SCRUM techniques (We are still very much learning this approach as a company) Use MVVM archectecture Use Ninject and DI where possible Attempt to use as TDD as much as possible to drive development. Keep our controllers as skinny as possible Keep our views as simple as possible During our discussions two approaches have been broached as too how to seperate the workload given our objectives outlined above. OPTION 1: A framework seperation where each person is responsible for conceptual areas with overlap and discussion primarily in the integration areas. The integration areas would the responsibily of both developers as required. View prototypes (**Graphic designer**) | - Mockups | Views (Razor and view helpers etc) & Javascript (**Developer 1**) | - View models (Integration point) | Controllers and Application logic (**Developer 2**) | - Models (Integration point) | Domain model and persistence (**Developer 3**) OPTION 2: A more task orientated approach where each person is responsible for the completion of the entire task (story) from view - controller - model. QUESTION: For those who have worked in small teams developing MVC projects how have you managed the workload distribution in this situation. I can't imagine the junior would be responsible for building parts of the underlying architecture so would given them responsibility for the view make sense considering we are trying to keep it simple?

    Read the article

  • Who determines what is best practice? [closed]

    - by dreza
    I've often searched for answers relating to "best practice" when writing code. And I see many questions regarding what is best practice. However, I was thinking the other day. Who actually determines what this best practice is? Is it the owners or creators of the programming language. Is it the general developer community that is writing in the language and it's just a gut feeling consensus. Is it whoever seems to have the highest prestige in the developer world and shouts the loudest? Is best practice really just another term for personal opinion? I hope this is a constructive question. If I could word it better to ensure it doesn't get closed please feel free to edit, or inform me otherwise.

    Read the article

  • Is inconsistent formatting a sign of a sloppy programmer?

    - by dreza
    I understand that everyone has their own style of programming and that you should be able to read other people's styles and accept it for what it is. However, would one be considered a sloppy programmer if one's style of coding was inconsistent across whatever standard they were working against? Some example of inconsistencies might be: Sometimes naming private variables with _ and sometimes not Sometimes having varying indentations within code blocks Not aligning braces up i.e. same column if using start using new line style Spacing not always consistent around operators i.e. p=p+1, p+=1 vs other times p =p+1 or p = p + 1 etc Is this even something that as a programmer I should be concerned with addressing? Or is it such a minor nit picking thing that at the end of the day I should just not worry about it and worry about what the end user sees and whether the code works rather than how it looks while working? Is it sloppy programming or just over obsessive nit picking? EDIT: After some excellent comments I realized I may have left out some information in my question. This question came about after reviewing another colleagues code check-in and noticing some of these things and then realizing that I've seen these kind of in-consistencies in previous check-ins. It then got me thinking about my code and whether I do the same things and noticed that I typically don't etc I'm not suggesting his technique is either bad or good in this question or whether his way of doing things is right or wrong. EDIT: To answer some queries to some more good feed back. The specific instance this review occurred in was using Visual Studio 2010 and programming in c# so I don't think the editor would cause any issues. In fact it should only help I would hope. Sorry if I left that piece of info out and it effects any current answers. I was trying to be a bit more generic in understanding if this would be considered sloppy etc. And to add an even more specific example of a code piece I saw during reading of the check-in: foreach(var block in Blocks) { // .. some other code in here foreach(var movement in movements) { movement.Moved.Zero(); } // the un-formatted brace } Such a minor thing I know, but many small things add up(???), and I did have to double glance at the code at the time to see where everything lined up I guess. Please note this code was formatted appropriately before this check-in. EDIT: After reading some great answers and varying thoughts, the summary I've taken from this was. It's not necessarily a sign of a sloppy programmer however as programmers we have a duty (to ourselves and other programmers) to make the code as readable as possible to assist in further ongoing development. However it can hint at inadequacies which is something that is only possible to review on a case by case (person by person) basis. There are many reasons why this might occur. They should be taken in context and worked through with the person/people involved if reasonable. We have a duty to try and help all programmers become better programmers! In the good old days when development was done using good old notepad (or other simple text editing tool) this occurred much more frequently. However we have the assistance of modern IDE's now so although we shouldn't necessarily become OTT about this, it should still probably be addressed to some degree. We as programmers vary in our standards, styles and approaches to solutions. However it seems that in general we all take PRIDE in our work and as a trait it is something that can stand programmers apart. Making something to the best of our abilities both internal (code) and external (end user result) goes along way to giving us that big fat pat on the back that we may not go looking for but swells our heart with pride. And finally to quote CrazyEddie from his post below. Don't sweat the small stuff

    Read the article

  • How vibrations might effect Kinect depth measurements

    - by dreza
    I'm currently doing some research into development with the Microsoft Kinect product. My project manager has come up with a potential design for mounting the camera to do the capturing. However the solution means that the camera might be subject to vibrations as the platform it is on is directly connected to where the subjects will be moving. It was my thought that vibrations would effect the quality of the results, however I could not come up with a viable explanation as to why, other than it's the same as if you held a camera in your hand and your hand was shaking vs using a tripod. Do vibrations effect the depth measurements on a Kinect and if so how can I explain this in simple terms to my PM to help come up with a better design to attach the sensor to?

    Read the article

  • Why use string.Empty over "" when assigning to a string object

    - by dreza
    I've been running StyleCop over my code and one of the recommendations SA1122 is to use string.Empty rather than "" when assigning an empty string to a value. My question is why is this considered best practice. Or, is this considered best practice? I assume there is no compiler difference between the two statements so I can only think that it's a readability thing? UPDATE: Thanks for the answers but it's been kindly pointed out this question has been asked many times already on SO, which in hind-sight I should have considered and searched first before asking here. Some of these especially forward links makes for interesting reading. SO question and answer Jon Skeet answer to question

    Read the article

  • Location of development solutions on disk - Common or upto the individual

    - by dreza
    In our team meeting today a senior member brought up the proposal that we should be having a common location/structure for our development solutions. A couple of his points were: Making it common meant when talking about projects and emailing stuff everyone is on the same wavelength and knows where to look. If there is ever the need to hard code a location path then it will work across all developers pc's. He had a more few points to back up his suggestion but I unfortunately got distracted during the discussion and so didn't hear all of them. I have no issue with the idea and can see it's merits but I was wondering if it is common or even recommended that all developers place their code in the same folder structure. Or do developers like to have the flexibility of location solutions where-ever they want? We currently use SVN for our version control. In this case his recommendation was to place all code in: c:\Work\Development\<Customer>\<project>\Code\<solution>\ the code I guess actual path is irrelevant for this question but added for completeness.

    Read the article

  • Seperation of project responsibilities in new project

    - by dreza
    We have very recently started a new project (MVC 3.0) and some of our early discussion has been around how the work and development will be split amongst the team members to ensure we get the least amount of overlap of work and so help make it a bit easier for each developer to get on and do their work. The project is expected to take about 6 months - 1 year (although not all developers are likely to be on and might filter off towards the end), Our team is going to be small so this will help out a bit I believe. The team will essentially consist of: 3 x developers (1 a slightly more experienced and will be the lead) 1 x project manager / product owner / tester An external company responsbile for doing our design work General project/development decisions so far have included: Develop in an Agile way using SCRUM techniques (We are still very much learning this approach as a company) Use MVVM archectecture Use Ninject and DI where possible Attempt to use as TDD as much as possible to drive development. Keep our controllers as skinny as possible Keep our views as simple as possible During our discussions two approaches have been broached as too how to seperate the workload given our objectives outlined above. OPTION 1: A framework seperation where each person is responsible for conceptual areas with overlap and discussion primarily in the integration areas. The integration areas would the responsibily of both developers as required. View prototypes (**Graphic designer**) | - Mockups | Views (Razor and view helpers etc) & Javascript (**Developer 1**) | - View models (Integration point) | Controllers and Application logic (**Developer 2**) | - Models (Integration point) | Domain model and persistence (**Developer 3**) PROS: Integration points are quite clear and so developers can work without dependencies on others fairly easily Code practices such as naming conventions and style is more easily managed in regards to consistancy as primarily only one developer will be handling an area CONS: Completion of an entire feature becomes a bit grey as no single person is responsible for an entire feature (story?) A person might not have a full appreciation for all areas of the project and so code overlap might be lacking if suddenly that person left. OPTION 2: A more task orientated approach where each person is responsible for the completion of the entire task from view - controller - model. PROS: A person is responsible for one entire feature so it's "complete" state can be clearly defined Code overlap into different areas will occur so each individual has good coverage over the entire application CONS: Overlap of development will occur in all the modules and developers can develop/extend without a true understanding of what the original code owner was intending. This could potentially lead more easily to code bloat? Following a convention might be harder as developers are adding to all areas of the project If a developer sets up a way of doing things would it be harder to enforce the other developers to follow that convention or even build on it (or even discuss it?). Dunno.. Bugs could more easily be introduced into areas not thought about by the developer It's easier to possibly to carry a team member in so far as one member just hacks code together to complete a task whilst another takes time to build a foundation that could be used by others and so help make future tasks easier i.e. starts building a framework? QUESTION: As it might appear I'm more in favor of option 1, however I'm interested to see how others might have approached this or what is the standard or best or preferred way of undertaking a project. Or indeed any different approach to handling this?

    Read the article

  • Creating a shared library that might be used with desktop applications and web projects

    - by dreza
    I have been involved in a number of MVC.NET and c# desktop projects in our company over the last year or so while also managing to kept my nose poked into other projects (in a read-only learning capacity of course). From this I've noticed that across the various projects and teams there is a-lot of functionality that has been well designed against good interfaces and abstractions. Because we tend to like our own work at times, I noticed a couple of projects had the exact same class, method copied into it as it had obviously worked on one and so was easily moved to a new project (probably by the same developer who originally wrote it) I mentioned this fact in one of our programmer meetings we have occasionally and suggested we pull some of this functionality into a core company library that we can build up over time and use across multiple projects. Everyone agreed and I started looking into this possibility. However, I've come across a stumbling block pretty early on. Our team primarily focuses on MVC at the moment and we have projects mainly in 2.0 but are starting to branch to 3.0. We also have a number of desktop applications that might benefit from some shared classes and basic helper methods. Initially when creating this DLL I included some shared classes that could be used across any project type (Web, Client etc) but then I started looking at adding some shared modules that would be useful in our MVC applications only. However this meant I had to include a reference to some Microsoft Web DLL's in order to leverage some of the classes I was creating (at this stage MVC 2.0). Now my issue is that we have a shared DLL that has references to web specific libraries that could also possibly be used in a client application. Not only that, our DLL referenced initially MVC 2.0 and we will eventually move onto MVC 3.0 for all projects. But alot of the classes in this library I expect to still be relevant to MVC 3 etc Our code within this DLL is separated into it's own namespaces such as: CompanyDLL.Primitives CompanyDLL.Web.Mvc CompanyDLL.Helpers etc etc So, my questions are: Is it OK to do a shared library like this, or if we have web specific features in it should we create a separate web DLL only targeted at a specific framework or MVC version? If it's OK, what kind of issues might we face when using the library that references MVC 2 in a MVC 3 project for example. I would be thinking that we might run into some sort of compatibility issue, or even issues where the developers using the library doesn't realize they need MVC 2.0 libraries. They might only want to use some of the generic classes etc The concept seemed like a good idea at the time, but I'm starting to think maybe it's not really a practical solution. But the number of times I've seen copied classes and methods across projects because they are proven tested code is a bit unnerving to be perfectly honest!

    Read the article

  • Should I leave href empty when implementing click events via jQuery?

    - by dreza
    Is it preferable to have # in a link's href attribute when I am implementing the click event via jQuery, or is it ok to leave href empty? i.e. <a id="myLink" href="#" /> vs <a id="myLink" href="" /> When I'm doing $("#myLink").on('click', function() { // do ajaxy stuff }); Although I understand the click event could be on a span or other such element I'm interested in this case for particular best practices when using an a tag.

    Read the article

  • How to refactor a method which breaks "The law of Demeter" principle?

    - by dreza
    I often find myself breaking this principle (not intentially, just through bad design). However recently I've seen a bit of code that I'm not sure of the best approach. I have a number of classes. For simplicity I've taken out the bulk of the classes methods etc public class Paddock { public SoilType Soil { get; private set; } // a whole bunch of other properties around paddock information } public class SoilType { public SoilDrainageType Drainage { get; private set; } // a whole bunch of other properties around soil types } public class SoilDrainageType { // a whole bunch of public properties that expose soil drainage values public double GetProportionOfDrainage(SoilType soil, double blockRatio) { // This method does a number of calculations using public properties // exposed off SoilType as well as the blockRatio value in some conditions } } In the code I have seen in a number of places calls like so paddock.Soil.Drainage.GetProportionOfDrainage(paddock.Soil, paddock.GetBlockRatio()); or within the block object itself in places it's Soil.Drainage.GetProportionOfDrainage(this.Soil, this.GetBlockRatio()); Upon reading this seems to break "The Law of Demeter" in that I'm chaining together these properties to access the method I want. So my thought in order to adjust this was to create public methods on SoilType and Paddock that contains wrappers i.e. on paddock it would be public class Paddock { public double GetProportionOfDrainage() { return Soil.GetProportionOfDrainage(this.GetBlockRatio()); } } on the SoilType it would be public class SoilType { public double GetProportionOfDrainage(double blockRatio) { return Drainage.GetProportionOfDrainage(this, blockRatio); } } so now calls where it used would be simply // used outside of paddock class where we can access instances of Paddock paddock.GetProportionofDrainage() or this.GetProportionOfDrainage(); // if used within Paddock class This seemed like a nice alternative. However now I have a concern over how would I enforce this usage and stop anyone else from writing code such as paddock.Soil.Drainage.GetProportionOfDrainage(paddock.Soil, paddock.GetBlockRatio()); rather than just paddock.GetProportionOfDrainage(); I need the properties to remain public at this stage as they are too ingrained in usage throughout the code block. However I don't really want a mixture of accessing the method on DrainageType directly as that seems to defeat the purpose altogether. What would be the appropiate design approach in this situation? I can provide more information as required to better help in answers. Is my thoughts on refactoring this even appropiate or should is it best to leave it as is and use the property chaining to access the method as and when required?

    Read the article

1